Thanks for the fixes, they look great! (Glad to have someone who knows what they are doing with respect to modules helping!) I have updated the PR with these changes and some additional unit testing I did of the behavior you outlined. I will merge these changes in at some point next week.
I understand the desire to not want to try to execute the tool shed actions if tool_shed_packages are not specified in the dependency resolvers list. I have created a Trello card for it (https://trello.com/c/CPeU3VlR). It sounds like the new status quo will be functional it will just be kind of annoying to have those actions try and fail and then marked as errors, right? If that is right then for this reason I don't think implementing this behavior will be a high priority for the team, but if you send another brilliant patch or pull request I will be happy to test it and merge it.
Thanks again for the contribution, -John
On Wed, Oct 2, 2013 at 9:43 PM, Guest, Simon Simon.Guest@agresearch.co.nz wrote:
This is in regard to this: https://bitbucket.org/galaxy/galaxy-central/pull-request/228/tool-dependency...
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:
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.
Made versionless fallback work, i.e. use the matching version if it exists, and only fallback to a generic match if it doesn't.
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:
<dependency_resolvers> <modules prefetch="false" versionless="true"/> </dependency_resolvers>
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 satisfied.
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?
cheers, Simon ======================================================================= 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. =======================================================================