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.