, On Thu, Feb 20, 2014 at 2:56 AM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
On Wed, Feb 19, 2014 at 9:33 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
In any case, we have a fix for out move_directory_files which Dave is now committing. So your tests should pass with tonight's run - Let's hope!
That explanation makes perfect sense to me - but I can see it took some digging to solve it!
There is actually one MIRA binary (mira) and several aliases (e.g. mirabait) which are really symlinks back to mira. Magic.
For anyone interested, the fix was this commit: https://bitbucket.org/galaxy/galaxy-central/commits/a89bbdfd4a71671d575d9a0a...
My next query would be: why wasn't the failing action <move_directory_files> being caught as a failed install?
Scanning over the code, some of the actions have explicit error handling but make_directory, move_directory_files, move_file and others do not. I guess any exception is propagated up... lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py
Your installation recipe for mira attempts to download a binary and if that fails, it echoes an error, but still performs <set_environment> actions..
Ah - I can see that now, I need a fall back <action> tag which either tries to compile MIRA or raises an explicit error. Thanks!
Here is the entire log of the installtion process that helped us uncover the problem - notice that upon failure of the initial binary installation, the process "proceeds with install and compile recipe for tool dependency MIRA".
Would it be a security risk to automatically expose these logs? Peter