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

Attachment: configurable-toolshed-package-installation.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:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to