fix infinite recursion when computing concretization
errors
+ environment: fix an issue with
deconcretization/reconcretization of specs
+ buildcache: don't error if a patch is missing, when
installing from binaries
In v0.18, we added better error messages that could tell you
what problem happened, but they couldn't tell you why it
happened. 0.21 adds condition chaining to the solver, and
Spack can now trace back through the conditions that led to
an error and build a tree of causes potential causes and
where they came from.
This creates a container image from the Spack installations
on the host system, without the need to run spack install
from a Dockerfile or sif file. It also addresses the
inconvenience of losing binaries of dependencies when RUN
spack install fails inside docker build. Further, the
container image layers and build cache tarballs are the same
files. This means that spack install and docker pull use the
exact same underlying binaries. If you previously used spack
install inside of docker build, this feature helps you save
storage by a factor two.
Increasingly, complex package builds require multiple
versions of some build dependencies. For example, Python
packages frequently require very specific versions of
setuptools, cython, and sometimes different physics packages
require different versions of Python to build. The
concretizer enforced that every solve was unified, i.e.,
that there only be one version of every package. The
concretizer now supports "duplicate" nodes for build