hlrs-software-stack/spack
7
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Typo fixes in Environments Tutorial (#12107)

Browse source
This commit is contained in:
Adam J. Stewart 2019-07-29 17:13:56 -05:00 committed by Greg Becker
parent 9af155f0f6
commit 23420a6524
1 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
lib/spack/docs/tutorial_environments.rst
View file

@ -5,9 +5,9 @@
.. _environments-tutorial: .. _environments-tutorial:
================================================ =====================
Environments, ``spack.yaml``, and ``spack.lock`` Environments Tutorial
================================================ =====================
We've shown you how to install and remove packages with Spack. You can We've shown you how to install and remove packages with Spack. You can
use :ref:`cmd-spack-install` to install packages, use :ref:`cmd-spack-install` to install packages,
@ -19,7 +19,7 @@ customize Spack's installation with configuration files like
If you build a lot of software, or if you work on multiple projects, If you build a lot of software, or if you work on multiple projects,
managing everything in one place can be overwhelming. The default ``spack managing everything in one place can be overwhelming. The default ``spack
find`` output may contain many packages, but you may want to *just* focus find`` output may contain many packages, but you may want to *just* focus
on packages a particular project. Moreover, you may want to include on packages for a particular project. Moreover, you may want to include
special configuration with your package groups, e.g., to build all the special configuration with your package groups, e.g., to build all the
packages in the same group the same way. packages in the same group the same way.
@ -710,7 +710,7 @@ install the project's dependencies. They need only clone the repository,
Spack concretizes the specs in the ``spack.yaml`` file and installs them. Spack concretizes the specs in the ``spack.yaml`` file and installs them.
What happened here? If you ``cd`` into a directory tha has a What happened here? If you ``cd`` into a directory that has a
``spack.yaml`` file in it, Spack considers this directory's environment ``spack.yaml`` file in it, Spack considers this directory's environment
to be activated. The directory does not have to live within Spack; it to be activated. The directory does not have to live within Spack; it
can be anywhere. can be anywhere.
@ -754,7 +754,7 @@ So, from ``~/code``, we can actually manipulate ``spack.yaml`` using
``spack.lock`` ``spack.lock``
^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
Ok, we've covered managed environments, environments in directories, and Okay, we've covered managed environments, environments in directories, and
the last thing we'll cover is ``spack.lock``. You may remember that when the last thing we'll cover is ``spack.lock``. You may remember that when
we ran ``spack install``, Spack concretized all the specs in the we ran ``spack install``, Spack concretized all the specs in the
``spack.yaml`` file and installed them. ``spack.yaml`` file and installed them.
@ -763,7 +763,7 @@ Whenever we concretize Specs in an environment, all concrete specs in the
environment are written out to a ``spack.lock`` file *alongside* environment are written out to a ``spack.lock`` file *alongside*
``spack.yaml``. The ``spack.lock`` file is not really human-readable ``spack.yaml``. The ``spack.lock`` file is not really human-readable
like the ``spack.yaml`` file. It is a ``json`` format that contains all like the ``spack.yaml`` file. It is a ``json`` format that contains all
the information that we need to ``reproduce`` the build of an the information that we need to *reproduce* the build of an
environment: environment:
.. code-block:: console .. code-block:: console
@ -802,11 +802,11 @@ be either a ``spack.yaml`` or a ``spack.lock`` file:
Both of these create a new environment called ``my-project``, but which Both of these create a new environment called ``my-project``, but which
one you choose to use depends on your needs: one you choose to use depends on your needs:
1. copying the yaml file allows someone else to build your *requirements*, #. copying the yaml file allows someone else to build your *requirements*,
potentially a different way. potentially a different way.
2. copying the lock file allows someone else to rebuild your #. copying the lock file allows someone else to rebuild your
*installation* exactly as you built it. *installation* exactly as you built it.
The first use case can *re-concretize* the same specs on new platforms in The first use case can *re-concretize* the same specs on new platforms in
order to build, but it will preserve the abstract requirements. The order to build, but it will preserve the abstract requirements. The