On Wednesday, June 1, 2011, Nate Coraor nate@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:
https://bitbucket.org/galaxy/galaxy-central/issue/565/ 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.
Peter