At Thu, 26 Sep 2013 22:03:09 -0400,
Greg Von Kuster wrote:
> Hi John,
> On Sep 26, 2013, at 9:15 PM, John Chilton <> wrote:
> > I was not even thinking we needed to modify the tool shed to implement
> > this. I was hoping (?) you could just modify:
> Nothing in the Tool Shed itself would be affected or require modification for 
> this new feature as this is completely on the Galaxy side.
> > 
> > lib/galaxy/tools/deps/
> > 
> > to implement this. If some tool contains the tag
> > 
> >  <requirement type="package" version="1.7.1">numpy</requirement>
> > 
> > then if there is a manually installed tool_dependency in
> > `tool_dependency_dir/numpy/1.7.1/` that would take precedence
> > over the tool shed installed version (would that be something like
> > `tool_dependency_dir/numpy/1.7.1/owner/name/changeset/`)? Let me
> > know if this is way off base.
> This is a possibility perhaps, but there seems to be a potential weakness in 
> that it doesn't require the Tool Dependency object to exist since the tool 
> will function without a installed dependency from the Tool Shed.  Or, if the 
> installed depndency s required, then it is meaningless because it won't be 
> used.  If the former case, then the tool dependency cannot be shared via the 
> Tool Shed's dependency mechanism because none of the relationships will be 
> defined  since nothing is installed.  Wouldn't it be better to allow the 
> Galaxy admin to point the ToolDependency object to a specified binary on 
> disk?  In this way, all relationships defined by Tool Shed installations will 
> work as expected, with all contained tools with that dependency point to that 
> same shared location on disk.

Hi Greg, John,

What you are discussing is pretty close to what I am after, and what I
am prepared to spend some time working on, if that can help.  This is
what I have posted about a couple of times previously.  The option to
use a pre-installed package rather than a Galaxy installed one I think
would be very useful in general.  I think it can be done in a way that
doesn't break the tool dependency model.

I envisage providing access to existing programs on disk by loading
the relevant environment module.  Platforms will differ greatly on
where they have programs installed (usr/local/bwa-0.5.9,
/usr/libexec/bwa-0.5.9, etc.).  However, we could arrange to have a
conventionally named environment module available, so Galaxy just has
to be told somehow to do a module load bwa/0.5.9, say, prior to
trying to run that tool, which will then be found on the PATH.

Hooking this in without killing the dependency on named and versioned
toolshed repos could work like this.  In parallel with the repo sets
named, e.g. package_bwa_0_5_9, which download and build the package,
we have a set named like native_package_bwa_0_5_9.  This could have a
tool_dependencies.xml file like this:

<?xml version="1.0"?>
    <native_package name="bwa" version="0.5.9">
            <action type="load_module">
                <module name="bwa" version="0.5.9"</module>
Uses native BWA via environment module bwa/0.5.9

What this does is ensure that any repo which requires version 0.5.9 of
bwa can have this dependency resolved by either package_bwa_0_5_9, or

I envisage a Galaxy configuration setting that enables native package
and/or Galaxy package dependency resolution, and which one should be
preferred.  Of course, if one of these has been manually installed, it
will be used as is.

I would really like to be able to install tools from the toolshed, and
have them resolve their dependencies automatically using my
preinstalled application suite.  I see that would also meet the needs
being discussed here.

How does that sound?


Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
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:

To search Galaxy mailing lists use the unified search at:

Reply via email to