docs: document how spack picks a version / variant (#41070)
This commit is contained in:
parent
e1f98fd206
commit
2cbe84b1ee
4 changed files with 93 additions and 1 deletions
|
@ -37,7 +37,11 @@ to enable reuse for a single installation, and you can use:
|
||||||
spack install --fresh <spec>
|
spack install --fresh <spec>
|
||||||
|
|
||||||
to do a fresh install if ``reuse`` is enabled by default.
|
to do a fresh install if ``reuse`` is enabled by default.
|
||||||
``reuse: true`` is the default.
|
``reuse: dependencies`` is the default.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
FAQ: :ref:`Why does Spack pick particular versions and variants? <faq-concretizer-precedence>`
|
||||||
|
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
Selection of the target microarchitectures
|
Selection of the target microarchitectures
|
||||||
|
|
77
lib/spack/docs/frequently_asked_questions.rst
Normal file
77
lib/spack/docs/frequently_asked_questions.rst
Normal file
|
@ -0,0 +1,77 @@
|
||||||
|
.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
|
||||||
|
Spack Project Developers. See the top-level COPYRIGHT file for details.
|
||||||
|
|
||||||
|
SPDX-License-Identifier: (Apache-2.0 OR MIT)
|
||||||
|
|
||||||
|
==========================
|
||||||
|
Frequently Asked Questions
|
||||||
|
==========================
|
||||||
|
|
||||||
|
This page contains answers to frequently asked questions about Spack.
|
||||||
|
If you have questions that are not answered here, feel free to ask on
|
||||||
|
`Slack <https://slack.spack.io>`_ or `GitHub Discussions
|
||||||
|
<https://github.com/spack/spack/discussions>`_. If you've learned the
|
||||||
|
answer to a question that you think should be here, please consider
|
||||||
|
contributing to this page.
|
||||||
|
|
||||||
|
.. _faq-concretizer-precedence:
|
||||||
|
|
||||||
|
-----------------------------------------------------
|
||||||
|
Why does Spack pick particular versions and variants?
|
||||||
|
-----------------------------------------------------
|
||||||
|
|
||||||
|
This question comes up in a variety of forms:
|
||||||
|
|
||||||
|
1. Why does Spack seem to ignore my package preferences from ``packages.yaml`` config?
|
||||||
|
2. Why does Spack toggle a variant instead of using the default from the ``package.py`` file?
|
||||||
|
|
||||||
|
The short answer is that Spack always picks an optimal configuration
|
||||||
|
based on a complex set of criteria\ [#f1]_. These criteria are more nuanced
|
||||||
|
than always choosing the latest versions or default variants.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
As a rule of thumb: requirements + constraints > reuse > preferences > defaults.
|
||||||
|
|
||||||
|
The following set of criteria (from lowest to highest precedence) explain
|
||||||
|
common cases where concretization output may seem surprising at first.
|
||||||
|
|
||||||
|
1. :ref:`Package preferences <package-preferences>` configured in ``packages.yaml``
|
||||||
|
override variant defaults from ``package.py`` files, and influence the optimal
|
||||||
|
ordering of versions. Preferences are specified as follows:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
packages:
|
||||||
|
foo:
|
||||||
|
version: [1.0, 1.1]
|
||||||
|
variants: ~mpi
|
||||||
|
|
||||||
|
2. :ref:`Reuse concretization <concretizer-options>` configured in ``concretizer.yaml``
|
||||||
|
overrides preferences, since it's typically faster to reuse an existing spec than to
|
||||||
|
build a preferred one from sources. When build caches are enabled, specs may be reused
|
||||||
|
from a remote location too. Reuse concretization is configured as follows:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
concretizer:
|
||||||
|
reuse: dependencies # other options are 'true' and 'false'
|
||||||
|
|
||||||
|
3. :ref:`Package requirements <package-requirements>` configured in ``packages.yaml``,
|
||||||
|
and constraints from the command line as well as ``package.py`` files override all
|
||||||
|
of the above. Requirements are specified as follows:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
packages:
|
||||||
|
foo:
|
||||||
|
require:
|
||||||
|
- "@1.2: +mpi"
|
||||||
|
|
||||||
|
Requirements and constraints restrict the set of possible solutions, while reuse
|
||||||
|
behavior and preferences influence what an optimal solution looks like.
|
||||||
|
|
||||||
|
|
||||||
|
.. rubric:: Footnotes
|
||||||
|
|
||||||
|
.. [#f1] The exact list of criteria can be retrieved with the ``spack solve`` command
|
|
@ -55,6 +55,7 @@ or refer to the full manual below.
|
||||||
getting_started
|
getting_started
|
||||||
basic_usage
|
basic_usage
|
||||||
replace_conda_homebrew
|
replace_conda_homebrew
|
||||||
|
frequently_asked_questions
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
|
@ -256,6 +256,11 @@ on the command line, because it can specify constraints on packages
|
||||||
is not possible to specify constraints on dependencies while also keeping
|
is not possible to specify constraints on dependencies while also keeping
|
||||||
those dependencies optional.
|
those dependencies optional.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
FAQ: :ref:`Why does Spack pick particular versions and variants? <faq-concretizer-precedence>`
|
||||||
|
|
||||||
|
|
||||||
^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^
|
||||||
Requirements syntax
|
Requirements syntax
|
||||||
^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -435,6 +440,11 @@ them if it must, due to other constraints, and also prefers reusing
|
||||||
installed packages over building new ones that are a better match for
|
installed packages over building new ones that are a better match for
|
||||||
preferences.
|
preferences.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
FAQ: :ref:`Why does Spack pick particular versions and variants? <faq-concretizer-precedence>`
|
||||||
|
|
||||||
|
|
||||||
Most package preferences (``compilers``, ``target`` and ``providers``)
|
Most package preferences (``compilers``, ``target`` and ``providers``)
|
||||||
can only be set globally under the ``all`` section of ``packages.yaml``:
|
can only be set globally under the ``all`` section of ``packages.yaml``:
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue