Concretization Settings (concretizer.yaml)
The concretizer.yaml
configuration file allows to customize aspects of the
algorithm used to select the dependencies you install. The default configuration
is the following:
# -------------------------------------------------------------------------
# This is the default spack configuration file.
#
# Settings here are versioned with Spack and are intended to provide
# sensible defaults out of the box. Spack maintainers should edit this
# file to keep it current.
#
# Users can override these settings by editing
# `$SPACK_ROOT/etc/spack/concretizer.yaml`, `~/.spack/concretizer.yaml`,
# or by adding a `concretizer:` section to an environment.
# -------------------------------------------------------------------------
concretizer:
# Whether to consider installed packages or packages from buildcaches when
# concretizing specs. If `true`, we'll try to use as many installs/binaries
# as possible, rather than building. If `false`, we'll always give you a fresh
# concretization. If `dependencies`, we'll only reuse dependencies but
# give you a fresh concretization for your root specs.
reuse: dependencies
# Options that tune which targets are considered for concretization. The
# concretization process is very sensitive to the number targets, and the time
# needed to reach a solution increases noticeably with the number of targets
# considered.
targets:
# Determine whether we want to target specific or generic
# microarchitectures. Valid values are: "microarchitectures" or "generic".
# An example of "microarchitectures" would be "skylake" or "bulldozer",
# while an example of "generic" would be "aarch64" or "x86_64_v4".
granularity: microarchitectures
# If "false" allow targets that are incompatible with the current host (for
# instance concretize with target "icelake" while running on "haswell").
# If "true" only allow targets that are compatible with the host.
host_compatible: true
# When "true" concretize root specs of environments together, so that each unique
# package in an environment corresponds to one concrete spec. This ensures
# environments can always be activated. When "false" perform concretization separately
# on each root spec, allowing different versions and variants of the same package in
# an environment.
unify: true
# Option to deal with possible duplicate nodes (i.e. different nodes from the same package) in the DAG.
duplicates:
# "none": allows a single node for any package in the DAG.
# "minimal": allows the duplication of 'build-tools' nodes only (e.g. py-setuptools, cmake etc.)
# "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
strategy: minimal
# Option to specify compatiblity between operating systems for reuse of compilers and packages
# Specified as a key: [list] where the key is the os that is being targeted, and the list contains the OS's
# it can reuse. Note this is a directional compatibility so mutual compatibility between two OS's
# requires two entries i.e. os_compatible: {sonoma: [monterey], monterey: [sonoma]}
os_compatible: {}
Reuse already installed packages
The reuse
attribute controls whether Spack will prefer to use installed packages (true
), or
whether it will do a “fresh” installation and prefer the latest settings from
package.py
files and packages.yaml
(false
).
You can use:
% spack install --reuse <spec>
to enable reuse for a single installation, and you can use:
spack install --fresh <spec>
to do a fresh install if reuse
is enabled by default.
reuse: dependencies
is the default.
See also
Selection of the target microarchitectures
The options under the targets
attribute control which targets are considered during a solve.
Currently the options in this section are only configurable from the concretizer.yaml
file
and there are no corresponding command line arguments to enable them for a single solve.
The granularity
option can take two possible values: microarchitectures
and generic
.
If set to:
concretizer:
targets:
granularity: microarchitectures
Spack will consider all the microarchitectures known to archspec
to label nodes for
compatibility. If instead the option is set to:
concretizer:
targets:
granularity: generic
Spack will consider only generic microarchitectures. For instance, when running on an
Haswell node, Spack will consider haswell
as the best target in the former case and
x86_64_v3
as the best target in the latter case.
The host_compatible
option is a Boolean option that determines whether or not the
microarchitectures considered during the solve are constrained to be compatible with the
host Spack is currently running on. For instance, if this option is set to true
, a
user cannot concretize for target=icelake
while running on an Haswell node.
Duplicate nodes
The duplicates
attribute controls whether the DAG can contain multiple configurations of
the same package. This is mainly relevant for build dependencies, which may have their version
pinned by some nodes, and thus be required at different versions by different nodes in the same
DAG.
The strategy
option controls how the solver deals with duplicates. If the value is none
,
then a single configuration per package is allowed in the DAG. This means, for instance, that only
a single cmake
or a single py-setuptools
version is allowed. The result would be a slightly
faster concretization, at the expense of making a few specs unsolvable.
If the value is minimal
Spack will allow packages tagged as build-tools
to have duplicates.
This allows, for instance, to concretize specs whose nodes require different, and incompatible, ranges
of some build tool. For instance, in the figure below the latest py-shapely requires a newer py-setuptools,
while py-numpy still needs an older version:
Up to Spack v0.20 duplicates:strategy:none
was the default (and only) behavior. From Spack v0.21 the
default behavior is duplicates:strategy:minimal
.