opensource/galaxy
3
0
Fork 0
mirror of https://github.com/galaxyproject/galaxy.git synced 2026-09-24 16:30:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #3708 from natefoo/dep-resolve-order

Browse Source 
Prefer versioned Conda dependencies to unversioned Galaxy ones
This commit is contained in:
Dannon Baker
2017-03-10 16:26:52 -05:00
committed by GitHub
parent 5a7eab0f06 45971b29bd
commit 33ff2754cc
3 changed files with 45 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
config/dependency_resolvers_conf.xml.sample
+22 -18
View File
@@ -1,28 +1,32 @@
<dependency_resolvers>
<!-- the default configuration, first look for dependencies installed from the toolshed -->
<!-- the default configuration, first look for dependencies installed from the toolshed -->
<tool_shed_packages />
<!-- then look for env.sh files in directories according to the "galaxy packages" schema.
These resolvers can take a base_path attribute to specify where to look for
package definitions, but by default look in the directory specified by tool_dependency_dir
in Galaxy's config/galaxy.ini -->
<!-- then look for env.sh files in directories according to the "galaxy packages" schema.
These resolvers can take a base_path attribute to specify where to look for
package definitions, but by default look in the directory specified by tool_dependency_dir
in Galaxy's config/galaxy.ini -->
<galaxy_packages />
<galaxy_packages versionless="true" />
<!-- check whether the correct version has been installed via conda -->
<conda />
<!-- look for a "default" symlink pointing to a directory containing an
env.sh file for the package in the "galaxy packages" schema -->
<galaxy_packages versionless="true" />
<!-- look for any version of the dependency installed via conda -->
<conda versionless="true" />
<!-- Example configuration of modules dependency resolver, uses Environment Modules -->
<!--
<!-- Example configuration of modules dependency resolver, uses Environment Modules -->
<!--
<modules modulecmd="/opt/Modules/3.2.9/bin/modulecmd" />
<modules modulecmd="/opt/Modules/3.2.9/bin/modulecmd" versionless="true" default_indicator="default" />
Attributes are:
* modulecmd - path to modulecmd
* versionless - default: false - whether to resolve tools using a version number or not
* find_by - directory or avail - use the DirectoryModuleChecker or AvailModuleChecker
* prefetch - default: true - in the AvailModuleChecker prefetch module info with 'module avail'
* default_indicator - default: '(default)' - what indicate to the AvailModuleChecker that a module is the default version
-->
<!-- other resolvers
Attributes are:
* modulecmd - path to modulecmd
* versionless - default: false - whether to resolve tools using a version number or not
* find_by - directory or avail - use the DirectoryModuleChecker or AvailModuleChecker
* prefetch - default: true - in the AvailModuleChecker prefetch module info with 'module avail'
* default_indicator - default: '(default)' - what indicate to the AvailModuleChecker that a module is the default version
-->
<!-- other resolvers
<tool_shed_tap />
<homebrew />
-->
</dependency_resolvers>
-->
</dependency_resolvers>
doc/source/admin/dependency_resolvers.rst
+22 -19
View File
@@ -6,10 +6,12 @@ Dependency Resolvers in Galaxy
There are two parts to building a link between Galaxy and command line bioinformatics tools: the tool XML that
specifies a mapping between the Galaxy web user interface and the tool command line and tool dependencies that specify
how to source the actual packages that implement the tool’s commands. The final script that Galaxy submits to run a
job uses includes commands, such as changes to the ``PATH`` environment variable, that are generated by *dependency
resolvers*. There is a default dependency resolver configuration but administrators can provide their own configuration
using the ``dependency_resolvers_conf.xml`` configuration file in the Galaxy ``config/`` directory.
how to source the actual packages that implement the tool’s commands. The final script that Galaxy submits to run a job
uses includes commands, such as changes to the ``PATH`` environment variable, that are generated by *dependency
resolvers*. These same dependency resolvers are used by the Galaxy administrative UI to display whether an installed
tool's dependencies have been installed on the Galaxy server, and to show how they will be resolved at job runtime.
There is a default dependency resolver configuration but administrators can provide their own configuration using the
``dependency_resolvers_conf.xml`` configuration file in the Galaxy ``config/`` directory.
The binding between tool XML and the tools they need to run is specified in the tool XML using ``<requirement>``
tags, for example
@@ -34,30 +36,31 @@ The default configuration of dependency resolvers is equivalent to the following
.. code-block:: xml
<dependency_resolvers>
<!-- the default configuration, first look for legacy dependencies installed from the toolshed -->
<tool_shed_packages />
<!-- then look for env.sh files profile according to the "galaxy packages" schema -->
<galaxy_packages />
<galaxy_packages versionless="true" />
<!-- finally look for Conda dependencies. -->
<conda />
<galaxy_packages versionless="true" />
<conda versionless="true" />
</dependency_resolvers>
This default dependency resolver configuration contains five items. First, the *tool shed dependency resolver* is used,
then the *Galaxy packages dependency resolver* is used (initially looking for packages by name and version string and then looking for the package just by name), and finally it checks *Conda* for a versioned or unversioned match.
The default configuration thus prefers packages installed from the Galaxy Tool Shed using legacy ``tool_dependencies.xml``
files, before trying to find a "Galaxy package" satisfying the specific version the dependency requires before
falling back to looking for a Galaxy package with merely the correct name, and then looking for Conda recipes with
matching name and version, and finally just for a Conda package with the correct name. If any of the dependency
resolvers succeeds a dependency resolution object is returned and no more resolvers are called. This dependency
resolution object provides shell commands to prepend to the shell script that runs the tool.
This default dependency resolver configuration contains five items:
1. First, the *Tool Shed dependency resolver* is used, which resolves packages installed from the Galaxy Tool Shed
using legacy ``tool_dependencies.xml`` files,
2. then the *Galaxy packages dependency resolver* is checked for a package matching the requirement name and version,
3. then the *Conda dependency resolver* is checked for a package matching the requirement name and version. If no
versioned match can be found, it then moves on to searching for unversioned matches, that is,
4. the *Galaxy packages dependency resolver* is checked for a package matching the required name only, and
5. finally the *Conda dependency resolver* is checked for a package matching the required name only.
If any of the dependency resolvers succeeds a dependency resolution object is returned and no more resolvers are
called. This dependency resolution object provides shell commands to prepend to the shell script that runs the tool.
This order can be thought of as a descending order of deliberation. Tool Shed dependencies must be declared next to the
tool by the tool author and must be selected for installation at tool installation time - this requires specific actions
by both the tool author and the deployer who installed the tools. The dependency is therefore expected to highly craft
to the individual tool. If Galaxy packages have been setup, the deployer of a Galaxy tool has purposely crafted tool
dependency statements for a specific installation - this is slightly less deliberate than tool shed packages but
by both the tool author and the deployer who installed the tools. The dependency is therefore expected to highly
crafted to the individual tool. If Galaxy packages have been setup, the deployer of a Galaxy tool has purposely crafted
tool dependency statements for a specific installation - this is slightly less deliberate than tool shed packages but
such requirements are less likely to be incidentally resolved than Conda packages. Conda recipes are neither tied to
tools or a specific installation and are maintained in Conda channels such as Bioconda.
lib/galaxy/tools/deps/__init__.py
+1 -1
View File
@@ -198,8 +198,8 @@ class DependencyManager( object ):
return [
ToolShedPackageDependencyResolver(self),
GalaxyPackageDependencyResolver(self),
GalaxyPackageDependencyResolver(self, versionless=True),
CondaDependencyResolver(self),
GalaxyPackageDependencyResolver(self, versionless=True),
CondaDependencyResolver(self, versionless=True),
]