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:
The BLAST+ packages have the same glitch in their fall-back (so I will need to update them on the main and test Tool Shed, although I will delay that pending your reply to the problem below): https://github.com/peterjc/galaxy_blast/commit/4b2fa1fbf485c4630cb6dc0beaf72...
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!
As we briefly discussed earlier, your mira4 recipe is not currently following best practices. Although you uncovered a problem in the framework which has now been corrected, your recipe's fall back <actions> tag set should be the recipe for installing mira4 from source ( http://sourceforge.net/projects/mira-assembler/ ) since there is no licensing issues for doing so. This would be a more ideal approach than echoing the error messages.
Thanks very much for helping us discover this problem though!
Greg Von Kuster
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? As to best practice for the fall back action, I think that needs a new thread. Regards, Peter