[galaxy-dev] The new hg based Galaxy Tool Shed
p.j.a.cock at googlemail.com
Wed Jun 1 15:42:43 EDT 2011
On Wednesday, June 1, 2011, Nate Coraor <nate at bx.psu.edu> wrote:
> Peter Cock wrote:
>> > ... but we want to move away from the situation where someone
>> > installs a "tool" but finds that it's unusable because the actual
>> > underlying dependency doesn't exist and is non-trivial to install.
>> Improving the documentation shown on the tool shed could help here -
>> make it easier for the tool wrapper to tell the Tool Shed user what will
>> be required.
>> Currently we get a short plain text box as part of the upload (no markup),
>> and can include a (plain text) readme file which is easily viewable from
>> the tool shed. I've just filed an enhancement request on a related idea:
>> Show mockup of tool GUI in Galaxy Tool Shed
> Yeah, eventually we'll have to parse the tool configs in the repo, so
> functionality like this should show up as the Shed matures. Not sure
> about the difficulty of doing the tool form mockup, but I like the idea.
That's a start :)
>> >> This larger aim of installing the underlying dependencies is impossible
>> >> in general - but that seems to be what you want to aim for. Consider
>> >> obvious use case of closed source (non-redistributable) 3rd party binaries.
>> >> I can think of several examples from the current Tool Shed wrappers,
>> >> including the Roche "Newbler" off instrument applications, TMHMM
>> >> and SignalP.
>> > Agreed, thankfully, the current dependency system (tool_dependency_dir
>> > in the config file (not in the sample config, sorry, I'll rememdy that
>> > shortly!)) only requires that you have an environment file that
>> > configures whatever is necessary (generally just $PATH) to find a
>> > dependency. So the tools in the Tool Shed would provide the XML,
>> > wrapper script (if necessary), and then instructions or perhaps an
>> > interface to configure the env file.
>> I'd hope the common case where all that is required is the tool binary
>> to be on the path, would not require any extra configuration files. See
>> also: https://bitbucket.org/galaxy/galaxy-central/issue/82
> Well, use of the dependency system isn't required, so just setting
> things up on the $PATH is always a possibility. I was going to suggest
> that your patch could be applied if it was conditional on the local
> runner and checked after any <requirement type="package">
> dependencies were setup, ...
Is that a request for me to update the patch? I've not delved into the
job runner code before, so it might take me a bit longer that it would
take you. Hint hint ;) I'd help with testing though.
> ... but there's still the problem of people running jobs through
> the local runner which are actually sent to the cluster without Galaxy's
> knowledge. Perhaps this is something we shouldn't worry too much about,
> but I know there are people doing it.
You mean if Galaxy blindly calls a tool or script, and that script
then submits the job to the cluster? I'd say checking the cluster
dependencies there was the tool author's responsibility.
More information about the galaxy-dev