Hi all,
Over on the test Tool Shed, I'm trying to include automated installation of NLStradamus as part of my wrapper for this NLS prediction tool. This should make things simper for end users, but is also intended to get the unit tests to pass on the Galaxy Tool Shed setup. The repo is here: http://testtoolshed.g2.bx.psu.edu/view/peterjc/nlstradamus
The unit tests are still failing, just saying:
Fatal error: Exit code 127 () /bin/sh: 1: NLStradamus: not found
The tool XML file contains an explicit package dependency:
<requirements> <requirement type="binary">NLStradamus</requirement> <requirement type="package" version="1.8">NLStradamus</requirement> </requirements>
That package dependency is defined using the tool_dependencies.xml file (in the same repository). My tool_dependencies.xml file should compile this binary, and have it added to the $PATH. This error message suggests that this did not work:
<?xml version="1.0"?> <tool_dependency> <package name="NLStradamus" version="1.8"> <install version="0.0.1"> <actions> <action type="download_by_url">http://www.moseslab.csb.utoronto.ca/NLStradamus/NLStradamus/NLStradamus.1.8....</action> <!-- Although v1.7 used a subfolder in the tar-ball, v1.8 did not --> <action type="shell_command">g++ NLStradamus.cpp -o NLStradamus -O3</action> <action type="move_file"><source>NLStradamus</source><destination>$INSTALL_DIR/</destination></action> <action type="set_environment"> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> ...
My question is was my tool_dependencies.xml file processed, and if so did it run without errors, and if so why didn't it work?
If there were errors processing the tool_dependencies.xml then I would hope the ToolShed would show them (and not silently overlook this and attempt to run the tests anyway). Is that the case?
Thanks,
Peter
Peter,
I noticed that the 'version' attribute of the install tag is set to '0.0.1', while the code currently only supports a version attribute of 1.0. When I duplicated the tool dependency xml locally and changed the version tag to:
<install version="1.0">
The tool dependency downloaded and compiled correctly.
Additionally, I would suggest changing the move_file action to:
<action type="move_file"><source>NLStradamus</source><destination>$INSTALL_DIR/bin/</destination></action>
So that it matches the $PATH environment variable setting.
--Dave B.
On 4/22/13 12:04:49.000, Peter Cock wrote:
Hi all,
Over on the test Tool Shed, I'm trying to include automated installation of NLStradamus as part of my wrapper for this NLS prediction tool. This should make things simper for end users, but is also intended to get the unit tests to pass on the Galaxy Tool Shed setup. The repo is here: http://testtoolshed.g2.bx.psu.edu/view/peterjc/nlstradamus
The unit tests are still failing, just saying:
Fatal error: Exit code 127 () /bin/sh: 1: NLStradamus: not found
The tool XML file contains an explicit package dependency:
<requirements> <requirement type="binary">NLStradamus</requirement> <requirement type="package" version="1.8">NLStradamus</requirement> </requirements>That package dependency is defined using the tool_dependencies.xml file (in the same repository). My tool_dependencies.xml file should compile this binary, and have it added to the $PATH. This error message suggests that this did not work:
<?xml version="1.0"?>
<tool_dependency> <package name="NLStradamus" version="1.8"> <install version="0.0.1"> <actions> <action type="download_by_url">http://www.moseslab.csb.utoronto.ca/NLStradamus/NLStradamus/NLStradamus.1.8.tar.gz</action> <!-- Although v1.7 used a subfolder in the tar-ball, v1.8 did not --> <action type="shell_command">g++ NLStradamus.cpp -o NLStradamus -O3</action> <action type="move_file"><source>NLStradamus</source><destination>$INSTALL_DIR/</destination></action> <action type="set_environment"> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> ...
My question is was my tool_dependencies.xml file processed, and if so did it run without errors, and if so why didn't it work?
If there were errors processing the tool_dependencies.xml then I would hope the ToolShed would show them (and not silently overlook this and attempt to run the tests anyway). Is that the case?
Thanks,
Peter ___________________________________________________________ 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/
On Mon, Apr 22, 2013 at 6:24 PM, Dave Bouvier dave@bx.psu.edu wrote:
Peter,
I noticed that the 'version' attribute of the install tag is set to '0.0.1', while the code currently only supports a version attribute of 1.0. When I duplicated the tool dependency xml locally and changed the version tag to:
<install version="1.0">
Do you mean it literally only looks for the string "1.0", which would make sense if this is referring the the XML mini-language the Galaxy Tool Shed is using (and not as I assumed the version of the installation script)?
Could you update the installation code to treat anything else as an error?
The tool dependency downloaded and compiled correctly.
Additionally, I would suggest changing the move_file action to:
<actiontype="move_file"><source>NLStradamus</source><destination>$INSTALL_DIR/bin/</destination></action>
So that it matches the $PATH environment variable setting.
Good catch - any preference for $INSTALL_DIR/bin/ versus simply $INSTALL_DIR alone? The later is shorter and some of the Galaxy command lines get very long and there are OS limits on command string lengths...
Thanks,
Peter
On 4/22/13 13:31:28.000, Peter Cock wrote:
On Mon, Apr 22, 2013 at 6:24 PM, Dave Bouvier dave@bx.psu.edu wrote:
Peter,
I noticed that the 'version' attribute of the install tag is set to '0.0.1', while the code currently only supports a version attribute of 1.0. When I duplicated the tool dependency xml locally and changed the version tag to:
<install version="1.0">Do you mean it literally only looks for the string "1.0", which would make sense if this is referring the the XML mini-language the Galaxy Tool Shed is using (and not as I assumed the version of the installation script)?
Yes, that is the current behavior, see http://wiki.galaxyproject.org/ToolShedToolFeatures#Supported_tags_sets_for_t...
Specifically the row that describes the <install> tag.
Could you update the installation code to treat anything else as an error?
Greg is currently in the process of updating the code to handle that situation.
The tool dependency downloaded and compiled correctly.
Additionally, I would suggest changing the move_file action to:
<actiontype="move_file"><source>NLStradamus</source><destination>$INSTALL_DIR/bin/</destination></action>
So that it matches the $PATH environment variable setting.
Good catch - any preference for $INSTALL_DIR/bin/ versus simply $INSTALL_DIR alone? The later is shorter and some of the Galaxy command lines get very long and there are OS limits on command string lengths...
There are points to be made in favor of either approach. On the one hand, putting compiled binaries under bin/ makes sense as a more posixy approach, but on the other hand, there are the command line length limits you pointed out. However, most of the operating systems I am familiar with have a fairly large upper limit, on the order of 32,768 or more characters. My recommendation would be to put binaries in bin/, just for consistency.
Thanks,
Peter
--Dave B.
On Apr 22, 2013, at 2:01 PM, Dave Bouvier wrote:
On 4/22/13 13:31:28.000, Peter Cock wrote:
On Mon, Apr 22, 2013 at 6:24 PM, Dave Bouvier dave@bx.psu.edu wrote:
Peter,
I noticed that the 'version' attribute of the install tag is set to '0.0.1', while the code currently only supports a version attribute of 1.0. When I duplicated the tool dependency xml locally and changed the version tag to:
<install version="1.0">Do you mean it literally only looks for the string "1.0", which would make sense if this is referring the the XML mini-language the Galaxy Tool Shed is using (and not as I assumed the version of the installation script)?
Yes, that is the current behavior, see http://wiki.galaxyproject.org/ToolShedToolFeatures#Supported_tags_sets_for_t...
Specifically the row that describes the <install> tag.
Could you update the installation code to treat anything else as an error?
Greg is currently in the process of updating the code to handle that situation.
This is the new behavior as of change set 9504:ea0b7ca55aec, which is now available on the test tool shed.
On Monday, April 22, 2013, Greg Von Kuster wrote:
On Apr 22, 2013, at 2:01 PM, Dave Bouvier wrote:
On 4/22/13 13:31:28.000, Peter Cock wrote:
On Mon, Apr 22, 2013 at 6:24 PM, Dave Bouvier <dave@bx.psu.edujavascript:;>
wrote:
Peter,
I noticed that the 'version' attribute of the install tag is set to
'0.0.1',
while the code currently only supports a version attribute of 1.0.
When I
duplicated the tool dependency xml locally and changed the version tag
to:
<install version="1.0">Do you mean it literally only looks for the string "1.0", which would make sense if this is referring the the XML mini-language the Galaxy Tool Shed is using (and not as I assumed the version of the installation script)?
Yes, that is the current behavior, see
http://wiki.galaxyproject.org/ToolShedToolFeatures#Supported_tags_sets_for_t...
Specifically the row that describes the <install> tag.
Yes, now that I've read that it is clear :)
Could you update the installation code to treat anything else as an error?
Greg is currently in the process of updating the code to handle that
situation.
This is the new behavior as of change set 9504:ea0b7ca55aec, which is now available on the test tool shed.
Great.
Peter
galaxy-dev@lists.galaxyproject.org
-
Dave Bouvier -
Greg Von Kuster -
Peter Cock