Hi Peter,
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:
http://testtoolshed.g2.bx.psu.edu/view/peterjc/effectivet3/c70df461aae5 http://testtoolshed.g2.bx.psu.edu/view/peterjc/clinod/20e44218fa63
I'm not sure, but can you try to fetch the first jar file with download_by_url. The last time I was struggling with that the download_by_url was required, if I remember correctly.
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.
Have a look at: lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py Hope that helps! Björn
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/