On Wed, Jun 1, 2011 at 5:25 PM, Nate Coraor <n...@bx.psu.edu> wrote:
> Peter Cock wrote:
>>
>> Well, yes and no - as long as there are competing versions of a Galaxy tool
>> (e.g. from an original author and a fork by a second author), and they use
>> the same ID in their XML, you have a clash. This will have to be considered
>> in the (automated) install interface. i.e. In general, when installing or
>> updating any tool, there may be existing versions of some components
>>  already present. In fact two completely unrelated tools could even have
>> the same XML ID by accident.
>
> I agree there could be a problem with tool ID uniqueness.  We've talked
> about suggesting that people namespace their tool IDs to prevent this,
> but nothing formal has materialized at this point.

That sounds sensible, and the sooner the better.

>> I'm not immediately sold on this plan. To me one of the big plus points
>> of having a single "Official" Tool Shed looked after by the Galaxy team
>> is the convenience factor (a one stop shop), which requires critical mass,
>> plus whatever QA happens as part of the current approval process. I
>> would regard it as a step backwards if in order to hunt for a wrapper for
>> a given tool, I had to resort to Google in order to find all the individual
>> Galaxy Tool Sheds.
>
> It'll be possible for people to run their own Tool Sheds if they'd like,
> for whatever purpose - and this may be necessary for sharing extremely
> large data which we can't possibly host at the main Shed, but there
> should be an aggregator somewhere which lists all of the available
> public Sheds and makes it easy to add them as new sources to your Galaxy
> install.  Like a slightly more organized Debian APT system.

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

>> If you mean by "dependencies" the small task of installing the tool XML
>> and associated scripts and data files currently bundled in the tar balls
>> on the current Tool Shed, that seems fine. Anything beyond that seems
>> difficult and likely to impose a significant extra load on tool wrapper
>> authors.
>
> It'll be up to the authors to decide what level of complexity they care
> to handle,

Good - that silences a lot of my worries.

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

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

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

  http://lists.bx.psu.edu/

Reply via email to