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, ``spack.yaml``, and ``spack.lock``
================================================
=====================
Environments Tutorial
=====================
We've shown you how to install and remove packages with Spack. You can
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,
managing everything in one place can be overwhelming. The default ``spack
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
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.
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
to be activated. The directory does not have to live within Spack; it
can be anywhere.
@ -754,7 +754,7 @@ So, from ``~/code``, we can actually manipulate ``spack.yaml`` using
``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
we ran ``spack install``, Spack concretized all the specs in the
``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*
``spack.yaml``. The ``spack.lock`` file is not really human-readable
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:
.. 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
one you choose to use depends on your needs:
1. copying the yaml file allows someone else to build your *requirements*,
potentially a different way.
#. copying the yaml file allows someone else to build your *requirements*,
potentially a different way.
2. copying the lock file allows someone else to rebuild your
*installation* exactly as you built it.
#. copying the lock file allows someone else to rebuild your
*installation* exactly as you built it.
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