On Thu, Mar 6, 2014 at 4:53 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
> On Feb 20, 2014, at 10:20 AM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>>> On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock <p.j.a.c...@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/4b2fa1fbf485c4630cb6dc0beaf7286cb103bd71
>>>
>>> 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/f5a119ac52a957204ab968a78638fe2a942c6893
> 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
___________________________________________________________
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