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.

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

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

> Even if you just hope to cover open source tool dependencies, this is
> another big problem which seems like something Galaxy shouldn't be
> taking on. Frankly the only way I expect this grand plan to have any
> practical chance of success is if you limit yourselves to a single existing
> Linux package management platform like RPM or Deb files (although
> doing that would limit Galaxy's appeal). e.g. Work hand in hand with
> Debian-Med to ensure any missing tool is covered.

Distributing binaries for the core platforms (Linux i686/x86_64) and Mac
OS X is probably not terribly difficult for us, but would be more work
for for 3rd party developers - but the choice to do this is up to them.
I also haven't given too much though about how this would work.  dpkg
and rpm have the upside of being deterministic, but the downside of
being platform-specific, requiring root, and not having much ability to
install to varying paths.

A fallback to source if binaries are not available would also be nice,
if it's possible to write some easy instructions on how to compile, but
of course this won't always be the case.

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

> (And for the umpteenth time, I am frustrated I couldn't make it to
> the Galaxy conference last week in person - more for this kind of
> discussion rather than the talks themselves. Will you be at BOSC
> or ISMB 2011 in Vienna? Maybe that could be another thread...)

Agreed!  I do believe there are some people going to BOSC, Dave will
hopefully chime in with the details (when he's awake, I think he was
only flying back today).

--nate

> 
> Regards,
> 
> 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/
> 
___________________________________________________________
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