Hi Peter, Regarding youyr previous question about why the more usefule log resutls are not returned for display in the Tool Shed, the reason is that our use of fabric's local command for installing tool dependnecies restricts us from bewing able to capture that information. We are currently working to eliminate the use of fabric for tool dependency installations - the Trello card is here: https://trello.com/c/zJoRROvv/147-eliminate-the-use-of-fabric-as-the-install... We should have this workling this week, after which better error logs can be treurned to the Tool Shed and several other Terello cards can be handled. See my inline comments below… On Feb 20, 2014, at 5:30 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Thu, Feb 20, 2014 at 2:56 AM, Greg Von Kuster <greg@bx.psu.edu> wrote:
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!
Sorry, slightly confused: there was a fallback <action> tag which was and is meant to raise an error. It was accidentally raising an error due to a bash syntax error in my unquoted echo (which that detailed log you posted alerted me to), now fixed in my repository and uploaded to the Test Tool Shed: https://github.com/peterjc/pico_galaxy/commit/4b003cf9b5e6baa15c75bb65723c5a... http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler
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.
Thanks,
Peter
P.S. The assert file exists action I suggested previously would be a neat way to catch some failing installs, e.g. here I expected the executables $MIRA4/mira and $MIRA4/mirabait etc to exist. I've filed a Trello card for this enhancement idea:
https://trello.com/c/xBUhFvj0/1446-add-assert-file-exists-and-directory-exis...
Thanks - I've moved it to the Tool Shed Trello Board - its in Project in Planning. Greg Von Kuster
___________________________________________________________ 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/