On Thu, Mar 6, 2014 at 5:24 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Thu, Mar 6, 2014 at 4:53 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
On Feb 20, 2014, at 10:20 AM, Greg Von Kuster <greg@bx.psu.edu> wrote:
On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
...
So, what happens is first the arch/os specific actions is tried, here <actions os="linux" architecture="x86_64">
That was failing with MIRA4 due to the symlink bug (now fixed). Because the platform specific action failed, the generic <actions> was used - where I deliberately try to raise an error to signal the installation failed.
What is surprising me is that the Tool Shed see the error, logs it, but still continues on (setting my environment variables, and reporting success). Why is that?
I'll need some time to investigate this behavior - if I discover a framework issue, I'll provide a fix.
The above issue should be corrected in https://bitbucket.org/galaxy/galaxy-central/commits/f5a119ac52a957204ab968a7... which is currently running on the Test Tool Shed. I'm going to wait for tonight's Install and Test run on the Test Tool Shed to make sure all is well with the fix. If things look good we'll graft the fix to the stable branch tomorrow. Thanks for reporting this!
...
Hi Greg,
No problem - I'm good at discovering problems ;)
If the download approach failed, it it most likely due to a transient error (e.g. network issues with download). Here I would much prefer Galaxy aborted and reported this as an error (and does not attempt the default action). Is that what you just fixed?
Re-reading the commit, and in particular the comment, it sounds like you have not fixed the larger issue I am trying to flag, quoting the commit comment:
Fixes to handle case where a tool dependency recipe defines an <actions_group> tag set for installing pre-compiled binaries which fail to install, so the fall back recipe for installing and compileing from souce is used. Prior to this change set, the recipe from source would not work, but the install process would finish in such a way that the recipe seemed to work.
i.e. The fall back action in my MIRA4 and BLAST+ recipes where I use "false" to raise an error should now be treated as an error (rather than as before being a silent failure). That's progress :) Given the current behaviour of switching to the default action if the platform specific action fails (which I think is unwise), does the Tool Shed clean up the failed platform specific installation before attempting the default action? e.g. The failed action may have downloaded and unzipped some files which could interfere. Thanks, Peter