Hi Dave,

that was fast.

Thanks a lot!
Björn


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



___________________________________________________________
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