At Fri, 4 Oct 2013 23:12:01 -0500, John Chilton wrote:
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.
Hi John,
I have now implemented this. Mercurial changeset attached.
This adds another configuration item for universe_wsgi.ini as documented in the updated universe_wsgi.ini.sample:
# This option may be used to disable installation of package # dependencies from tool sheds, which usually means downloading a # source tarball and compiling it locally. You would disable this if # you want to make use of system installed packages for example. In # that case, alternative tool dependency resolvers should be # configured in dependency_resolvers_conf.xml #enable_tool_shed_package_dependency_installation = True
The default behaviour is per standard toolshed. If configured to False, then the package components of tool dependencies will never be installed from the toolshed. Rather, they will rely on the tool dependency manager to resolve the requirement. This is integrated with the missing_tool_dependencies status, so that if dependency resolution fails, the repository gets flagged with "missing tool dependencies" on the installed tool shed repositories page, and the paster.log file contains a warning of exactly what wasn't found. Of course, if the dependency can be satisfied, then it's green lights all the way, and everything should work fine.
I've tested this interactively by installing the standard emboss_5 repository, with various combinations of environment module available and not. It looks to work fine. I'm afraid I haven't yet read up on the Galaxy unit testing framework, so no unit tests for now.
What do you think?
cheers, Simon