Simon, 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.gu...@agresearch.co.nz> wrote: > Hi John, > > This is in regard to this: > https://bitbucket.org/galaxy/galaxy-central/pull-request/228/tool-dependency-resolver-plugins-revision/diff > > 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: > > <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. > ======================================================================= ___________________________________________________________ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
