Peter Cock wrote:
> If there is an official "meta tool shed" aggregator, that would address
> my main concern about fragmenting things.

If nothing else, there can be a wiki page, although something
programatic would be more ideal.

> > ... 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.

> >> 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:

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, 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.


> > [cut]
> >
> >> Are you biting off more than you can chew? I hope I am misinterpreting
> >> your plans.
> >
> > Hopefully not!  We're trying to think this through pretty thoroughly
> > before we get started, thanks for joining in the discussion. =)
> I've been reassured :)
> 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:

Reply via email to