Hi Peter,
On Mar 6, 2014, at 1:07 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > On Thu, Mar 6, 2014 at 5:24 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote: >> 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: >>>>> >>>>> ... >>>>> >>>>> 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! >>> >>> ... >> >> 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 :) Yes, thanks! > > Given the current behaviour of switching to the default > action if the platform specific action fails (which I think is > unwise), It's fine if you want to display errors rather than an install from source recipe. You have ample justification for that approach in this case. > does the Tool Shed clean up the failed platform > specific installation before attempting the default action? Yes. > e.g. The failed action may have downloaded and unzipped > some files which could interfere. The tool shed will inspect and remove the contents of the installation directory before attempting to install from source. > > Thanks, > > 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/ ___________________________________________________________ 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/
