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.gruening@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/