Peter,

Yes, jar files are just a directory of .class (and other) files packaged with the zip algorithm, which has its benefits and drawbacks, as you've discovered. In the new action type I'm working on, I do intend to include the option to extract a downloaded file, or leave it as-is, which will allow the download of jar files needed at build time or run time, as well as any other compressed file that should not be automatically extracted.

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