Hi John,

This is in regard to this:

Overall, this is very useful, just what I need, thanks.  I'd *really*
like to see this feature in the mainline Galaxy.  Is there some voting
necessary on Trello to achieve this, or is it enough to be
enthusiastic here?

I tested the ModuleDependencyResolver, and fixed three problems:

1. Fixed up module loading to work properly.  The problem is that
   'module' is not a first class command, it's a shell function.  And
   it only works from interactive shells.  The solution is to use the
   underlying modulecmd command.  This requires deeper knowledge in
   the modules resolver of how environment modules work, which
   obviates the DEFAULT_MODULE_COMMAND and the flexibility to
   override it.

2. Made versionless fallback work, i.e. use the matching version if
   it exists, and only fallback to a generic match if it doesn't.

3. Enhanced the DirectoryModuleChecker to look along the modulepath,
   not just in a single directory.  The default path is initialised
   appropriately from environment variables MODULEPATH, MODULESHOME,
   as per module(1).  This can be overridden with the attribute
   modulepath rather than directory in the config file.

Fix attached - I presume a Mercurial export is all you need?

It may be better to default prefetch to false (but I didn't change
that).  Otherwise the Galaxy server needs restarting after new system
packages become available.

Now, there's one more thing required, which I'm not sure how to
achieve.  I intend to run with this config:

  <modules prefetch="false" versionless="true"/>

So in particular I'm not interested in tool_shed_packages.  However,
when I install from the toolshed, say, the emboss tool, it still
downloads the source tarball and tries to compile it locally (which
fails, as I don't have make installed on my production Galaxy, nor do
I want it).  The emboss tool status in the "Manage installed tool shed
repositories" list is "Installed, missing tool dependencies", but
actually my installed modules mean the tool dependencies are

The behaviour I'm after is not even to try to do the actions in a
tool_dependency.xml package spec in the toolshed, if I have dependency
resolvers configured without tool_shed_packages.

What are your thoughts on that?


Attachment: module-dependency-resolver-fix.patch
Description: Binary data

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