Peter,

As of 9696:b4733e42a2c9, Galaxy now supports an additional tool dependency installation action called download_file, which downloads a file from the specified URL and saves it to the current working directory, without extracting it. The format is:

<action type="download_file">[url]</action>

For your effectivet3 repository, the recommended tool_dependencies.xml now looks like:

<?xml version="1.0"?>
<tool_dependency>
    <package name="effectiveT3" version="1.0.1">
        <install version="1.0">
            <actions>
                <!-- Download jar files required by this tool. -->
<action type="download_file">http://effectors.org/download/version/TTSS_GUI-1.0.1.jar</action> <action type="move_file"><source>TTSS_GUI-1.0.1.jar</source><destination>$INSTALL_DIR/</destination></action>
                <action type="make_directory">$INSTALL_DIR/module</action>
<action type="download_file">http://effectors.org/download/module/TTSS_ANIMAL-1.0.1.jar</action> <action type="download_file">http://effectors.org/download/module/TTSS_PLANT-1.0.1.jar</action> <action type="download_file">http://effectors.org/download/module/TTSS_STD-1.0.1.jar</action> <action type="move_file"><source>TTSS_PLANT-1.0.1.jar</source><destination>$INSTALL_DIR/module/</destination></action> <action type="move_file"><source>TTSS_STD-1.0.1.jar</source><destination>$INSTALL_DIR/module/</destination></action> <action type="move_file"><source>TTSS_ANIMAL-1.0.1.jar</source><destination>$INSTALL_DIR/module/</destination></action> <!-- Set environment variable so Python script knows where to look -->
                <action type="set_environment">
<environment_variable name="EFFECTIVET3" action="set_to">$INSTALL_DIR</environment_variable>
                </action>
            </actions>
        </install>
        <readme>
Downloads effectiveT3 v1.0.1 and the three models from http://effectors.org/
        </readme>
    </package>
</tool_dependency>

An enhancement I intend to make on Monday is the option to specify a target path and filename, which will eliminate the need for the move_file steps you see in the above XML.

As this is a new feature, if you discover any bugs or anomalous behavior, please feel free to let me know, and I'll get that resolved as soon as I can.

   --Dave B.

On 5/10/13 11:13:36.000, Peter Cock wrote:
On Fri, May 10, 2013 at 2:59 PM, Björn Grüning
<bjoern.gruen...@pharmazie.uni-freiburg.de> wrote:
Hi Peter,

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

That is educational, thanks Björn :)

The good news is that the shell_command handling code does
check the return code and record an error if it failed as part of
the tool_dependency object (status and error_message).

The bad news is that in general install_and_build_package
doesn't seem to catch any other errors - for instance a
failing download, corrupt zip file, invalid path name, etc.

Further bad news, it looks like by guess about the JAR
files wrongly being unzipped was accurate - digging
down the imports, the common_util.iszip function seems
to just be doing this:

import zipfile
zipfile.is_zipfile("/opt/clinod/clinod-1.3.jar")
True

Therefore (right now) as I feared, we cannot use the
download_by_url action with JAR files because it will
unzip them. As suggested earlier, one fix would be an
option for controlling any decompression (defaulting to
automatic as now, but allowing it to be explicitly set to
true or false?).

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/

___________________________________________________________
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/

Reply via email to