On 4/22/13 13:31:28.000, Peter Cock wrote:
On Mon, Apr 22, 2013 at 6:24 PM, Dave Bouvier <d...@bx.psu.edu> wrote:
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:
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
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
The tool dependency downloaded and compiled correctly.
Additionally, I would suggest changing the move_file action to:
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.
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:
To search Galaxy mailing lists use the unified search at: