2016-05-22 05:33:05 +08:00
|
|
|
.. _configuration:
|
2014-01-05 06:43:44 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
==============================
|
|
|
|
Configuration Files in Spack
|
|
|
|
==============================
|
|
|
|
|
|
|
|
Spack has many configuration files. Here is a quick list of them, in
|
|
|
|
case you want to skip directly to specific docs:
|
|
|
|
|
|
|
|
* :ref:`compilers.yaml <compiler-config>`
|
|
|
|
* :ref:`config.yaml <config-yaml>`
|
|
|
|
* :ref:`mirrors.yaml <mirrors>`
|
|
|
|
* :ref:`modules.yaml <modules>`
|
|
|
|
* :ref:`packages.yaml <build-settings>`
|
2016-12-12 16:54:20 +08:00
|
|
|
* :ref:`repos.yaml <repositories>`
|
2016-10-29 07:17:58 +08:00
|
|
|
|
|
|
|
-------------------------
|
|
|
|
YAML Format
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
Spack configuration files are written in YAML. We chose YAML because
|
|
|
|
it's human readable, but also versatile in that it supports dictionaries,
|
|
|
|
lists, and nested sections. For more details on the format, see `yaml.org
|
|
|
|
<http://yaml.org>`_ and `libyaml <http://pyyaml.org/wiki/LibYAML>`_.
|
|
|
|
Here is an example ``config.yaml`` file:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
config:
|
|
|
|
install_tree: $spack/opt/spack
|
|
|
|
module_roots:
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
build_stage:
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
|
|
|
|
|
|
|
Each spack configuration files is nested under a top-level section
|
|
|
|
corresponding to its name. So, ``config.yaml`` starts with ``config:``,
|
|
|
|
and ``mirrors.yaml`` starts with ``mirrors:``, etc.
|
|
|
|
|
|
|
|
.. _configuration-scopes:
|
|
|
|
|
|
|
|
-------------------------
|
|
|
|
Configuration Scopes
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
Spack pulls configuration data from files in several directories. There
|
2017-06-17 03:31:56 +08:00
|
|
|
are four configuration scopes. From lowest to highest:
|
2016-10-29 07:17:58 +08:00
|
|
|
|
2017-06-17 03:31:56 +08:00
|
|
|
#. **defaults**: Stored in ``$(prefix)/etc/spack/defaults/``. These are
|
2016-10-29 07:17:58 +08:00
|
|
|
the "factory" settings. Users should generally not modify the settings
|
|
|
|
here, but should override them in other configuration scopes. The
|
|
|
|
defaults here will change from version to version of Spack.
|
|
|
|
|
2017-06-17 03:31:56 +08:00
|
|
|
#. **system**: Stored in ``/etc/spack``. These are settings for this
|
|
|
|
machine, or for all machines on which this file system is
|
|
|
|
mounted. The site scope can be used for settings idiosyncratic to a
|
|
|
|
particular machine, such as the locations of compilers or external
|
|
|
|
packages. These settings are presumably controlled by someone with
|
|
|
|
root access on the machine.
|
|
|
|
|
|
|
|
#. **site**: Stored in ``$(prefix)/etc/spack/``. Settings here affect
|
2016-10-29 07:17:58 +08:00
|
|
|
only *this instance* of Spack, and they override defaults. The site
|
|
|
|
scope can can be used for per-project settings (one spack instance per
|
|
|
|
project) or for site-wide settings on a multi-user machine (e.g., for
|
|
|
|
a common spack instance).
|
|
|
|
|
2016-12-30 10:13:55 +08:00
|
|
|
3. **user**: Stored in the home directory: ``~/.spack/``. These settings
|
|
|
|
affect all instances of Spack and take higher precedence than site or
|
|
|
|
default scopes.
|
|
|
|
|
|
|
|
3. **command line**: Optionally specified by the user on the command
|
|
|
|
line. These settings take the highest precedence. If multiple
|
|
|
|
scopes are listed on the command line, they are ordered from lowest
|
|
|
|
to highest precedence.
|
2016-10-29 07:17:58 +08:00
|
|
|
|
|
|
|
Each configuration directory may contain several configuration files,
|
|
|
|
such as ``config.yaml``, ``compilers.yaml``, or ``mirrors.yaml``. When
|
|
|
|
configurations conflict, settings from higher-precedence scopes override
|
|
|
|
lower-precedence settings.
|
|
|
|
|
|
|
|
Commands that modify scopes (e.g., ``spack compilers``, ``spack repo``,
|
|
|
|
etc.) take a ``--scope=<name>`` parameter that you can use to control
|
|
|
|
which scope is modified. By default they modify the highest-precedence
|
|
|
|
scope.
|
|
|
|
|
2016-12-30 10:13:55 +08:00
|
|
|
.. _command-line-scopes:
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
Command-line Scopes
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
In addition to the ``system``, ``site``, and ``user`` scopes, you may add
|
|
|
|
configuration scopes directly on the command line with the
|
|
|
|
``--config-scope`` argument, or ``-C`` for short.
|
|
|
|
|
|
|
|
For example, the following adds two configuration scopes, named `scopea`
|
|
|
|
and `scopeb`, to a `spack spec` command:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
$ spack -C ~/myscopes/scopea -C ~/myscopes/scopeb spec ncurses
|
|
|
|
|
|
|
|
Command-line scopes come *after* the ``spack`` command and *before* the
|
|
|
|
subcommand, and they specify a single path to a directory full of
|
|
|
|
configuration files. You can add the same configuration files to that
|
|
|
|
directory that you can add to any other sope (``config.yaml``,
|
|
|
|
``packages.yaml``, etc.).
|
|
|
|
|
|
|
|
If multiple scopes are provided:
|
|
|
|
|
|
|
|
1. each must be preceded with the ``--config-scope`` or ``-C`` flag.
|
|
|
|
2. they must be ordered from lowest to highest precedence.
|
|
|
|
|
|
|
|
"""""""""""""""""""""""""""""""""""""""""""
|
|
|
|
Example: scopes for release and development
|
|
|
|
"""""""""""""""""""""""""""""""""""""""""""
|
|
|
|
|
|
|
|
suppose that you need to support simultaneous building of release and
|
|
|
|
development versions of a `mypackage`, where `mypackage` -> `A` -> `B`.
|
|
|
|
You could create The following files:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
~/myscopes/release/packages.yaml
|
|
|
|
--------------------------------
|
|
|
|
packages:
|
|
|
|
mypackage:
|
|
|
|
version: [1.7]
|
|
|
|
A:
|
|
|
|
version: [2.3]
|
|
|
|
B:
|
|
|
|
version: [0.8]
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
~/myscopes/develop/packages.yaml
|
|
|
|
--------------------------------
|
|
|
|
packages:
|
|
|
|
mypackage:
|
|
|
|
version: [develop]
|
|
|
|
A:
|
|
|
|
version: [develop]
|
|
|
|
B:
|
|
|
|
version: [develop]
|
|
|
|
|
|
|
|
You can switch between ``release`` and ``develop`` configurations using
|
|
|
|
configuration arguments. You would type ``spack -C ~/myscopes/release``
|
|
|
|
when you want to build the designated release versions of ``mypackage``,
|
|
|
|
``A``, and ``B``, and you would type ``spack -C ~/myscopes/develop`` when
|
|
|
|
you want to build all of these packages at the ``develop`` version.
|
|
|
|
|
|
|
|
"""""""""""""""""""""""""""""""
|
|
|
|
Example: swapping MPI providers
|
|
|
|
"""""""""""""""""""""""""""""""
|
|
|
|
|
|
|
|
Suppose that you need to build two software packages, `packagea` and
|
|
|
|
`packageb`. PackageA is Python2-based and PackageB is Python3-based.
|
|
|
|
PackageA only builds with OpenMPI and PackageB only builds with MPICH.
|
|
|
|
You can create different configuration scopes for use with Package A and
|
|
|
|
B:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
~/myscopes/packgea/packages.yaml
|
|
|
|
--------------------------------
|
|
|
|
packages:
|
|
|
|
python:
|
|
|
|
version: [2.7.11]
|
|
|
|
all:
|
|
|
|
providers:
|
|
|
|
mpi: [openmpi]
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
~/myscopes/packageb/packages.yaml
|
|
|
|
--------------------------------
|
|
|
|
packages:
|
|
|
|
python:
|
|
|
|
version: [3.5.2]
|
|
|
|
all:
|
|
|
|
providers:
|
|
|
|
mpi: [mpich]
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
.. _platform-scopes:
|
|
|
|
|
|
|
|
-------------------------
|
|
|
|
Platform-specific scopes
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
For each scope above, there can *also* be platform-specific settings.
|
2017-06-17 03:31:56 +08:00
|
|
|
For example, on Blue Gene/Q machines, Spack needs to know the location
|
|
|
|
of cross-compilers for the compute nodes. This configuration is in
|
|
|
|
``etc/spack/defaults/bgq/compilers.yaml``. It will take precedence
|
|
|
|
over settings in the ``defaults`` scope, but can still be overridden
|
|
|
|
by settings in ``system``, ``system/bgq``, ``site``, ``site/bgq``,
|
|
|
|
``user``, or ``user/bgq``. So, the full scope precedence is:
|
2016-10-29 07:17:58 +08:00
|
|
|
|
|
|
|
1. ``defaults``
|
|
|
|
2. ``defaults/<platform>``
|
2017-06-17 03:31:56 +08:00
|
|
|
3. ``system``
|
|
|
|
4. ``system/<platform>``
|
|
|
|
5. ``site``
|
|
|
|
6. ``site/<platform>``
|
|
|
|
7. ``user``
|
|
|
|
8. ``user/<platform>``
|
2016-12-30 10:13:55 +08:00
|
|
|
9. ``command-line``
|
|
|
|
10. ``command-line/<platform>``
|
2016-10-29 07:17:58 +08:00
|
|
|
|
|
|
|
You can get the name to use for ``<platform>`` by running ``spack arch
|
2017-06-17 03:31:56 +08:00
|
|
|
--platform``. The system config scope has a ``<platform>`` section for
|
|
|
|
sites at which ``/etc`` is mounted on multiple heterogeneous machines.
|
2016-10-29 07:17:58 +08:00
|
|
|
|
|
|
|
-------------------------
|
|
|
|
Scope precedence
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
When spack queries for configuration parameters, it searches in
|
|
|
|
higher-precedence scopes first. So, settings in a higher-precedence file
|
|
|
|
can override those with the same key in a lower-precedence one. For
|
|
|
|
list-valued settings, Spack *prepends* higher-precedence settings to
|
|
|
|
lower-precedence settings. Completely ignoring higher-level configuration
|
|
|
|
options is supported with the ``::`` notation for keys (see
|
|
|
|
:ref:`config-overrides` below).
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Simple keys
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
Let's look at an example of overriding a single key in a Spack file. If
|
|
|
|
your configurations look like this:
|
|
|
|
|
|
|
|
**defaults** scope:
|
2015-10-06 05:04:33 +08:00
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
config:
|
|
|
|
install_tree: $spack/opt/spack
|
|
|
|
module_roots:
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
build_stage:
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
|
|
|
|
|
|
|
**site** scope:
|
2015-10-06 05:04:33 +08:00
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
config:
|
|
|
|
install_tree: /some/other/directory
|
2015-10-06 05:04:33 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
Spack will only override ``install_tree`` in the ``config`` section, and
|
|
|
|
will take the site preferences for other settings. You can see the
|
|
|
|
final, combined configuration with the ``spack config get <configtype>``
|
|
|
|
command:
|
2015-10-06 05:04:33 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
.. code-block:: console
|
|
|
|
:emphasize-lines: 3
|
2016-06-28 04:52:48 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
$ spack config get config
|
|
|
|
config:
|
|
|
|
install_tree: /some/other/directory
|
|
|
|
module_roots:
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
build_stage:
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
|
|
|
$ _
|
2016-03-11 08:18:11 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
.. _config-overrides:
|
2016-10-06 04:00:27 +08:00
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2016-10-29 07:17:58 +08:00
|
|
|
Overriding entire sections
|
2016-10-06 04:00:27 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
Above, the site ``config.yaml`` only overrides specific settings in the
|
|
|
|
default ``config.yaml``. Sometimes, it is useful to *completely*
|
|
|
|
override lower-precedence settings. To do this, you can use *two* colons
|
|
|
|
at the end of a key in a configuration file. For example, if the
|
|
|
|
**site** ``config.yaml`` above looks like this:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
:emphasize-lines: 1
|
|
|
|
|
|
|
|
config::
|
|
|
|
install_tree: /some/other/directory
|
2016-10-06 04:00:27 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
Spack will ignore all lower-precedence configuration under the
|
|
|
|
``config::`` section:
|
2016-10-06 04:00:27 +08:00
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
$ spack config get config
|
|
|
|
config:
|
|
|
|
install_tree: /some/other/directory
|
2016-10-06 04:00:27 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
List-valued settings
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
2016-10-06 04:00:27 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
Let's revisit the ``config.yaml`` example one more time. The
|
|
|
|
``build_stage`` setting's value is an ordered list of directories:
|
2016-10-06 04:00:27 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
**defaults**
|
2016-08-25 05:55:00 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
build_stage:
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
2016-05-22 05:33:05 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
Suppose the user configuration adds its *own* list of ``build_stage``
|
|
|
|
paths:
|
2016-05-22 05:33:05 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
**user**
|
2016-05-22 05:33:05 +08:00
|
|
|
|
2016-08-27 05:41:00 +08:00
|
|
|
.. code-block:: yaml
|
2016-05-22 05:33:05 +08:00
|
|
|
|
2016-10-29 07:17:58 +08:00
|
|
|
build_stage:
|
|
|
|
- /lustre-scratch/$user
|
|
|
|
- ~/mystage
|
|
|
|
|
|
|
|
Spack will first look at the paths in the site ``config.yaml``, then the
|
|
|
|
paths in the user's ``~/.spack/config.yaml``. The list in the
|
|
|
|
higher-precedence scope is *prepended* to the defaults. ``spack config
|
|
|
|
get config`` shows the result:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
:emphasize-lines: 7-10
|
|
|
|
|
|
|
|
$ spack config get config
|
|
|
|
config:
|
|
|
|
install_tree: /some/other/directory
|
|
|
|
module_roots:
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
build_stage:
|
|
|
|
- /lustre-scratch/$user
|
|
|
|
- ~/mystage
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
|
|
|
$ _
|
|
|
|
|
|
|
|
As in :ref:`config-overrides`, the higher-precedence scope can
|
|
|
|
*completely* override the lower-precedence scope using `::`. So if the
|
|
|
|
user config looked like this:
|
|
|
|
|
|
|
|
**user**
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
:emphasize-lines: 1
|
|
|
|
|
|
|
|
build_stage::
|
|
|
|
- /lustre-scratch/$user
|
|
|
|
- ~/mystage
|
|
|
|
|
|
|
|
The merged configuration would look like this:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
:emphasize-lines: 7-8
|
|
|
|
|
|
|
|
$ spack config get config
|
|
|
|
config:
|
|
|
|
install_tree: /some/other/directory
|
|
|
|
module_roots:
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
build_stage:
|
|
|
|
- /lustre-scratch/$user
|
|
|
|
- ~/mystage
|
|
|
|
$ _
|
2017-08-22 09:35:00 +08:00
|
|
|
|
|
|
|
.. _config-file-variables:
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
Config file variables
|
|
|
|
------------------------------
|
|
|
|
|
2018-06-24 15:48:02 +08:00
|
|
|
Spack understands several variables which can be used in config file
|
|
|
|
paths wherever they appear. There are three sets of these variables,
|
|
|
|
Spack specific variables, environment variables, and user path
|
|
|
|
variables. Spack specific variables and environment variables both are
|
|
|
|
indicated by prefixing the variable name with ``$``. User path variables
|
|
|
|
are indicated at the start of the path with ``~`` or ``~user``. See below
|
|
|
|
for more details.
|
2017-08-22 09:35:00 +08:00
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
2018-06-24 15:48:02 +08:00
|
|
|
Spack-specific variables
|
2017-08-22 09:35:00 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
Spack understands several special variables. These are:
|
|
|
|
|
|
|
|
* ``$spack``: path to the prefix of this spack installation
|
|
|
|
* ``$tempdir``: default system temporary directory (as specified in
|
|
|
|
Python's `tempfile.tempdir
|
|
|
|
<https://docs.python.org/2/library/tempfile.html#tempfile.tempdir>`_
|
|
|
|
variable.
|
|
|
|
* ``$user``: name of the current user
|
|
|
|
|
|
|
|
Note that, as with shell variables, you can write these as ``$varname``
|
|
|
|
or with braces to distinguish the variable from surrounding characters:
|
2018-06-24 15:48:02 +08:00
|
|
|
``${varname}``. Their names are also case insensitive, meaning that
|
|
|
|
``$SPACK`` works just as well as ``$spack``. These special variables are
|
|
|
|
substituted first, so any environment variables with the same name will
|
|
|
|
not be used.
|
2017-08-22 09:35:00 +08:00
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2018-06-24 15:48:02 +08:00
|
|
|
Environment variables
|
2017-08-22 09:35:00 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2018-06-24 15:48:02 +08:00
|
|
|
After spack-specific variables are evaluated, environment variables are
|
|
|
|
expanded. These are formatted like spack-specific variables, e.g.,
|
|
|
|
``${varname}``. You can use this to insert environment variables in your
|
|
|
|
Spack configuration.
|
2017-08-22 09:35:00 +08:00
|
|
|
|
2018-06-24 15:48:02 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
User home directories
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
Spack performs unix-style tilde expansion on paths in configuration
|
|
|
|
files. This means that tilde (``~``) will expand to the current user's
|
|
|
|
home directory, and ``~user`` will expand to a specified user's home
|
|
|
|
directory. The ``~`` must appear at the beginning of the path, or Spack
|
|
|
|
will not expand it.
|
|
|
|
|
|
|
|
----------------------------
|
|
|
|
Seeing Spack's configuration
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
With so many scopes overriding each other, it can sometimes be difficult
|
|
|
|
to understand what Spack's final configuration looks like. ``spack
|
|
|
|
config get`` shows a fully merged configuration file, taking into account
|
|
|
|
all scopes. For example, to see the fully merged ``config.yaml``, you
|
|
|
|
can type:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
$ spack config get config
|
|
|
|
config:
|
|
|
|
debug: false
|
|
|
|
checksum: true
|
|
|
|
verify_ssl: true
|
|
|
|
dirty: false
|
|
|
|
build_jobs: 8
|
|
|
|
install_tree: $spack/opt/spack
|
|
|
|
template_dirs:
|
|
|
|
- $spack/templates
|
|
|
|
directory_layout: ${ARCHITECTURE}/${COMPILERNAME}-${COMPILERVER}/${PACKAGE}-${VERSION}-${HASH}
|
|
|
|
module_roots:
|
|
|
|
tcl: $spack/share/spack/modules
|
|
|
|
lmod: $spack/share/spack/lmod
|
|
|
|
dotkit: $spack/share/spack/dotkit
|
|
|
|
build_stage:
|
|
|
|
- $tempdir
|
|
|
|
- /nfs/tmp2/$user
|
|
|
|
- $spack/var/spack/stage
|
|
|
|
source_cache: $spack/var/spack/cache
|
|
|
|
misc_cache: ~/.spack/cache
|
|
|
|
locks: true
|
|
|
|
|
|
|
|
Likewise, this will show the fully merged ``packages.yaml``:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
$ spack config get packages
|
|
|
|
|
|
|
|
You can use this in conjunction with the ``-C`` / ``--config-scope`` argument to
|
|
|
|
see how your scope will affect Spack's configuration:
|
|
|
|
|
|
|
|
.. code-block:: console
|
2017-08-22 09:35:00 +08:00
|
|
|
|
2018-06-24 15:48:02 +08:00
|
|
|
$ spack -C /path/to/my/scope config get packages
|