Very cool! I have two concerns. Rather than adding a new
configuration option I think I would prefer to just check the
configured dependency resolvers and then infer from them if the tool
shed will be used. The configuration option strikes me as having to
configure the same thing twice, and this change would make your setup
slightly easier. Do you have any objection to me reworking your patch
to do this? On the other hand, perhaps it is made more clear to the
deployer that they are definitely disabling tool dependency
installations if they have to add the explicit option this way.

  Greg, Dave have you looked at this? In particular, do you think
there are any downsides to marking a ToolDependency as installed if
nothing has actually been installed by Galaxy? Would it be better to


P.S. I know I said I would merge that module stuff last week, but is running off of galaxy-central right now and I am
being extra cautious about not breaking galaxy. It will get merged

On Thu, Oct 10, 2013 at 7:55 PM, Guest, Simon
<> wrote:
> 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
>> ( 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
> =======================================================================
> 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:

To search Galaxy mailing lists use the unified search at:

Reply via email to