Manipulating dependencies¶
A couple of different ways are available to manipulate the list of dependencies that are specified for the software packages being installed.
Contents
Filtering out dependencies using --filter-deps
¶
To avoid that certain dependencies are being installed, a list of software names can be specified to --filter-deps
.
Any time a dependency with a name from this list is specified, it will be simply filtered out by EasyBuild, and
thus disregarded when resolving dependencies, loading modules for the dependencies in the build environment, and
including ‘module load
‘ statements in the generated module files.
This can be useful when particular tools and libraries are already provided by OS packages (or in some other way), and should not be reinstalled as modules by EasyBuild.
For example:
overview of dependencies of HDF5:
$ eb HDF5-1.8.13-intel-2015a.eb -D ... * [ ] $CFGS/i/intel/intel-2015a.eb (module: intel/2015a) * [ ] $CFGS/z/zlib/zlib-1.2.8-intel-2015a.eb (module: zlib/1.2.8-intel-2015a) * [ ] $CFGS/s/Szip/Szip-2.1-intel-2015a.eb (module: Szip/2.1-intel-2015a) * [ ] $CFGS/h/HDF5/HDF5-1.8.13-intel-2015a.eb (module: HDF5/1.8.13-intel-2015a)
overview of dependencies of HDF5, with zlib and Szip excluded:
$ eb HDF5-1.8.13-intel-2015a.eb --filter-deps=zlib,Szip -D ... * [ ] $CFGS/i/intel/intel-2015a.eb (module: intel/2015a) * [ ] $CFGS/h/HDF5/HDF5-1.8.13-intel-2015a.eb (module: HDF5/1.8.13-intel-2015a)
Using minimal toolchains for dependencies¶
Note
This is an experimental feature, see Experimental features.
By default, EasyBuild will try to resolve dependencies using the same toolchain as the one that is used for the software being installed, unless a specific toolchain is specified for the dependency itself (see Dependencies).
Using the --minimal-toolchains
configuration option, you can instruct EasyBuild to consider subtoolchains
as well for dependencies. This can be useful to refrain from having to frequently hardcode specific toolchains in order
to avoid having the same dependency version installed with multiple toolchains that are compatible with each other.
Although hardcoding toolchain for dependencies will work fine, it severly limits the power of other EasyBuild features,
like --try-toolchain
for example.
When instructed to use minimal toolchains, EasyBuild will check whether an easyconfig file is available (in the robot search path, see Searching for easyconfigs: the robot search path) for that dependency using the different subtoolchains of the toolchain specified for the ‘parent’ software. Subtoolchains are considered ‘bottom-up’, i.e. starting with the most minimal subtoolchain (typically a compiler-only toolchain), and then climbing up towards the toolchain that is specified for the software being installed.
Note that if a specific toolchain is specified for a particular dependency, EasyBuild will stick to using it, even when instructed to use minimal toolchains.
Considering dummy
as minimal toolchain¶
The dummy toolchain is only considered as the most minimal subtoolchain if the
--add-dummy-to-minimal-toolchains
configuration option is enabled.
By default, this configuration option is disabled.
Taking existing modules into account¶
You can instruct EasyBuild to take existing modules into account when determining which subtoolchain should be used
for each of the dependencies, using the --use-existing-modules
configuration option.
By default existing modules are ignored, meaning that the EasyBuild dependency resolution mechanism will pick a
minimal toolchain for each dependency solely based on the available easyconfig files (if the --minimal-toolchains
configuration option is enabled, that is).
With --use-existing-modules
enabled, EasyBuild will first check whether modules exist for the dependencies that were
built with any of the subtoolchains. If so, the module using the most minimal toolchain will determine the toolchain
being used. If not, the toolchain to use will be determined based on the available easyconfig files.
Example¶
Consider the following (partial) easyconfig file for Python v2.7.9 with the foss/2015b
toolchain:
name = 'Python'
version = '2.7.9'
toolchain = {'name': 'foss', 'version': '2015b'}
dependencies = [
('zlib', '1.2.8'),
]
When the --minimal-toolchains
configuration option is enabled, EasyBuild will also consider the subtoolchains
GCC/4.9.3
and gompi/2015b
of the foss/2015b
toolchain (in that order) as potential minimal toolchains
when determining the toolchain to use for dependencies.
So, for the zlib v1.2.8 dependency included in the example above, the following scenarios are possible:
- without the use of
--minimal-toolchains
, EasyBuild will only consider thefoss/2015b
toolchain for zlib, even if other zlib easyconfigs using a compatible toolchain are available - if (only)
--minimal-toolchains
is enabled, EasyBuild will search for an easyconfig file for zlib v1.2.8 using theGCC/4.9.3
toolchain; if no such easyconfig file is found, it will continue searching using thegompi/2015b
toolchain, and finally thefoss/2015b
toolchain - if
--add-dummy-to-minimal-toolchains
is also enabled, EasyBuild will try locating an easyconfig file for zlib v1.2.8 that uses thedummy
toolchain prior to consider theGCC/4.9.3
toolchain - additionally, with
--use-existing-modules
enabled, EasyBuild will first check whether azlib
module for version 1.2.8 built with the (sub)toolchains being considered exists; if not, it will search for an easyconfig file for zlib as outlined above