On Wednesday, June 1, 2011, Nate Coraor <n...@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 ___________________________________________________________ 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/
