picard and package_picard_1_56_0
Devteam: On 10/23 an update was posted to package_picard_1_56_0 that breaks tool Picard. Since 10/23, picard depends on package_picard_1_56_0, which in turn depends on picard 1.122.0, but that dependency makes absolutely no sense. Now when I run PairedReadMateFixer I get: #################### ## exit code=1; stdout= Error: Unable to access jarfile /FixMateInformation.jar #################### which appears to be caused by bad paths I don't understand toolshed logic for revisions: when I install tools with very specific revisions, the tool depends on very specific revisions of other tools. However, when I install a tool that depends on a package_*, the package has revision information, but it is ignored in favor of installing the LATEST revision of the package. If someone posts a buggy revision of a package_* to the toolshed, there is no way to avoid installing it until a fixed version is posted in its place. For example, when I run: python ./scripts/api/install_tool_shed_repositories.py --api XXXXXXXXXX --local http://127.0.0.1:8080 --url http://toolshed.g2.bx.psu.edu --name package_picard_1_56_0 --owner devteam --revision 61e41d21cb6f --tool-deps --repository-deps --panel-section-name "Other (Main Tool Shed)"' I expect package_picard_1_56_0:61e41d21cb6f to be installed, but instead I get package_picard_1_56_0:4a49481f29e7: ####### Response -------- /api/tool_shed_repositories/03501d7626bd192f name: package_picard_1_56_0 status: Installed tool_shed_status: {u'latest_installable_revision': u'True', u'revision_update': u'False', u'revision_upgrade': u'False', u'repository_deprecated': u'False'} deleted: False ctx_rev: 1 error_message: dist_to_shed: False tool_shed: toolshed.g2.bx.psu.edu installed_changeset_revision: 4a49481f29e7 uninstalled: False owner: devteam changeset_revision: 4a49481f29e7 id: 03501d7626bd192f includes_datatypes: False ####### Why ignore the package revisions? Btw, I did find an alternate (and working) package_picard_1_56_0 in the test toolshed, but why do I need to depend on the test toolshed for a production environment? -Evan Bollig Research Associate | Application Developer | User Support Consultant Minnesota Supercomputing Institute 599 Walter Library 612 624 1447 evan@msi.umn.edu boll0107@umn.edu
Evan, Thank you for reporting this issue, it has now been corrected. --Dave B. On 11/11/2014 12:56 PM, Evan Bollig PhD wrote:
Devteam:
On 10/23 an update was posted to package_picard_1_56_0 that breaks tool Picard. Since 10/23, picard depends on package_picard_1_56_0, which in turn depends on picard 1.122.0, but that dependency makes absolutely no sense.
Now when I run PairedReadMateFixer I get: #################### ## exit code=1; stdout= Error: Unable to access jarfile /FixMateInformation.jar #################### which appears to be caused by bad paths
I don't understand toolshed logic for revisions: when I install tools with very specific revisions, the tool depends on very specific revisions of other tools. However, when I install a tool that depends on a package_*, the package has revision information, but it is ignored in favor of installing the LATEST revision of the package. If someone posts a buggy revision of a package_* to the toolshed, there is no way to avoid installing it until a fixed version is posted in its place.
For example, when I run:
python ./scripts/api/install_tool_shed_repositories.py --api XXXXXXXXXX --local http://127.0.0.1:8080 --url http://toolshed.g2.bx.psu.edu --name package_picard_1_56_0 --owner devteam --revision 61e41d21cb6f --tool-deps --repository-deps --panel-section-name "Other (Main Tool Shed)"'
I expect package_picard_1_56_0:61e41d21cb6f to be installed, but instead I get package_picard_1_56_0:4a49481f29e7:
####### Response -------- /api/tool_shed_repositories/03501d7626bd192f name: package_picard_1_56_0 status: Installed tool_shed_status: {u'latest_installable_revision': u'True', u'revision_update': u'False', u'revision_upgrade': u'False', u'repository_deprecated': u'False'} deleted: False ctx_rev: 1 error_message: dist_to_shed: False tool_shed: toolshed.g2.bx.psu.edu installed_changeset_revision: 4a49481f29e7 uninstalled: False owner: devteam changeset_revision: 4a49481f29e7 id: 03501d7626bd192f includes_datatypes: False #######
Why ignore the package revisions?
Btw, I did find an alternate (and working) package_picard_1_56_0 in the test toolshed, but why do I need to depend on the test toolshed for a production environment?
-Evan Bollig Research Associate | Application Developer | User Support Consultant Minnesota Supercomputing Institute 599 Walter Library 612 624 1447 evan@msi.umn.edu boll0107@umn.edu ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Thanks Dave, Everything is back to normal again. Cheers, -E -Evan Bollig Research Associate | Application Developer | User Support Consultant Minnesota Supercomputing Institute 599 Walter Library 612 624 1447 evan@msi.umn.edu boll0107@umn.edu On Tue, Nov 11, 2014 at 2:20 PM, Dave Bouvier <dave@bx.psu.edu> wrote:
Evan,
Thank you for reporting this issue, it has now been corrected.
--Dave B.
On 11/11/2014 12:56 PM, Evan Bollig PhD wrote:
Devteam:
On 10/23 an update was posted to package_picard_1_56_0 that breaks tool Picard. Since 10/23, picard depends on package_picard_1_56_0, which in turn depends on picard 1.122.0, but that dependency makes absolutely no sense.
Now when I run PairedReadMateFixer I get: #################### ## exit code=1; stdout= Error: Unable to access jarfile /FixMateInformation.jar #################### which appears to be caused by bad paths
I don't understand toolshed logic for revisions: when I install tools with very specific revisions, the tool depends on very specific revisions of other tools. However, when I install a tool that depends on a package_*, the package has revision information, but it is ignored in favor of installing the LATEST revision of the package. If someone posts a buggy revision of a package_* to the toolshed, there is no way to avoid installing it until a fixed version is posted in its place.
For example, when I run:
python ./scripts/api/install_tool_shed_repositories.py --api XXXXXXXXXX --local http://127.0.0.1:8080 --url http://toolshed.g2.bx.psu.edu --name package_picard_1_56_0 --owner devteam --revision 61e41d21cb6f --tool-deps --repository-deps --panel-section-name "Other (Main Tool Shed)"'
I expect package_picard_1_56_0:61e41d21cb6f to be installed, but instead I get package_picard_1_56_0:4a49481f29e7:
####### Response -------- /api/tool_shed_repositories/03501d7626bd192f name: package_picard_1_56_0 status: Installed tool_shed_status: {u'latest_installable_revision': u'True', u'revision_update': u'False', u'revision_upgrade': u'False', u'repository_deprecated': u'False'} deleted: False ctx_rev: 1 error_message: dist_to_shed: False tool_shed: toolshed.g2.bx.psu.edu installed_changeset_revision: 4a49481f29e7 uninstalled: False owner: devteam changeset_revision: 4a49481f29e7 id: 03501d7626bd192f includes_datatypes: False #######
Why ignore the package revisions?
Btw, I did find an alternate (and working) package_picard_1_56_0 in the test toolshed, but why do I need to depend on the test toolshed for a production environment?
-Evan Bollig Research Associate | Application Developer | User Support Consultant Minnesota Supercomputing Institute 599 Walter Library 612 624 1447 evan@msi.umn.edu boll0107@umn.edu ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
participants (2)
-
Dave Bouvier -
Evan Bollig PhD