On Thu, May 9, 2013 at 4:39 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:
> Hi all,
> For defining the 'install script' for some of my tool wrappers, I have
> mainly following http://wiki.galaxyproject.org/ToolShedToolFeatures
> and looking at one or two examples.
> I've got some of my tools to work, but not all. For instance, this one
> appears not to be downloading or moving JAR files correctly:
> http://testtoolshed.g2.bx.psu.edu/view/peterjc/effectivet3/5644c28cf965
> ...
> Here my Python wrapper script has evidently read the $EFFECTIVET3
> environment variable (defined in the tool_dependencies.xml to point
> to the tool's $INSTALL_DIR), but the JAR file isn't there:
> Effective T3 JAR file not found:
> /var/opt/buildslaves/buildslave-ec2-1/buildbot-install-test-test-tool-shed-py27/build/test/install_and_test_tool_shed_repositories/tmp/tmpYR9FXD/effectiveT3/1.0.1/peterjc/effectivet3/5644c28cf965/TTSS_GUI-1.0.1.jar
> My previous revision set the $EFFECTIVET3 environment variable
> at the end of the tool_dependencies.xml file, and from the test failure
> it appeared not to be getting set. My hunch is something breaks
> part way through the installation but the Tool Shed isn't reporting
> this - or am I just not looking in the right place? It would make
> sense to show any installation issues under the "Tool Dependencies"
> entry on the main tool page.
> Related to this, I'd like to suggest another couple of assertion action
> types, used for checking if directories or files exist, which would
> abort the installation with a clear error if the check fails:
> <action type="assert_dir_exists">$INSTALL_DIR/module/</action>
> <action 
> type="assert_file_exists">$INSTALL_DIR/module/TTSS_STD-1.0.1.jar</action>
> An obvious application of these would be immediately after an
> <action type="download_by_url"> line to sanity test the download
> (and decompression) worked as expected - and didn't for example
> just download an HTML error page for instance.
> (In this case I am worried that perhaps the download_by_url
> action has been overly enthusiastic and unzipped the JAR file,
> perhaps based on the mime-type?).
> Thanks,
> Peter

Thanks for the input Björn and Greg about not being able to make
multiple calls to download_by_url - I've tried tweaking both the
effectivet3 and clinod tool_dependencies.xml files to use wget
but they are still failing:


I believe that either I have a simple error in both install descriptions,
leading to the install to 'work' but not put things where I expect them
(which is my problem), or the install is really failing yet there is no
feedback about this (which is a Galaxy Tool Shed problem).

The idea of my new <action> types for checking if files and folders
exist is to catch some types of install failure as early as possible -
in this case verify the install put the relevant files where it was
intended to.

Could you direct me at the source code which handles running
the tool_dependencies.xm install scripts? I'd like to look at what
kind of error handling it does (e.g. I'd hope non-zero return codes
from a shell_command <action> would be treated as an error),
and how easy it would be to add the new actions myself.



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:

Reply via email to