ISC26: small typo and grammar fixes in env and stacks sections

tutorial_environments.rst

@@ -19,8 +19,8 @@ So far in this tutorial, we've covered the basic commands for managing individua
 .. Customizing Spack's installation with configuration files, like
    `packages.yaml <https://spack.readthedocs.io/en/latest/build_settings.html#build-settings>`_, was also discussed.
 
-Now we'll explore Spack Environments, a powerful feature that lets us manage collections of packages together in a documented and reproducible way.
-Spack environments are similar to *virtual environments* in other package managers (e.g., `Python venv <https://docs.python.org/3/library/venv.html>`_, `Conda Environments <https://docs.conda.io/projects/conda/en/stable/user-guide/getting-started.html>`_, or `nix-env <https://nix.dev/manual/nix/2.24/command-ref/nix-env>`_).
+Now we'll explore Spack environments, a powerful feature that lets us manage collections of packages together in a documented and reproducible way.
+Spack environments are similar to *virtual environments* in other package managers (e.g., `Python venv <https://docs.python.org/3/library/venv.html>`_, `Conda environments <https://docs.conda.io/projects/conda/en/stable/user-guide/getting-started.html>`_, or `nix-env <https://nix.dev/manual/nix/2.24/command-ref/nix-env>`_).
 
 Managing a software stack with many packages and varying configuration can quickly become hard to track by hand.
 An environment lets you:
@@ -116,7 +116,7 @@ First, we *add* our two specs with ``spack add``:
 .. literalinclude:: outputs/environments/env-add-1.out
    :language: console
 
-``tcl`` and ``trilinos`` are now registered as **root specs** i.e. the packages we've explicitly requested.
+``tcl`` and ``trilinos`` are now registered as **root specs**, i.e., the packages we've explicitly requested.
 They're called **"roots"** because they sit at the top of the dependency graph, with their dependency packages sitting below them.
 
 If we run ``spack find`` now, it lists them as roots but reports nothing concretized yet.
@@ -205,7 +205,7 @@ Let's build a small program that uses both MPI and ``zlib``:
 .. literalinclude:: outputs/environments/use-mpi-1.out
    :language: console
 
-If we look at the full set of path variables activation set:
+If we look at the full set of path variables set by activation:
 
 .. literalinclude:: outputs/environments/show-paths-1.out
    :language: console
@@ -304,7 +304,7 @@ Environments can also be *independent*, with their files placed in any directory
 The directory holds the two files that define the environment:
 
 * ``spack.yaml``: the *manifest* file containing the abstract specs we asked for plus configuration settings.
-* ``spack.lock``: the *lockfile* contaning the concrete specs generated whenever the environment is concretized.
+* ``spack.lock``: the *lockfile* containing the concrete specs generated whenever the environment is concretized.
 
 ``spack.yaml`` is the human-readable file we have been editing indirectly with ``spack add`` and ``spack remove``:
 

tutorial_packaging.rst

@@ -182,7 +182,7 @@ Let's make the following changes:
 
 Now make the changes and additions to your ``package.py`` file.
 
-The resulting package should contain -- sans the copyright and license -- the following information:
+The resulting package should contain the following information, omitting the copyright and license:
 
 .. literalinclude:: tutorial/examples/packaging/1.package.py
    :caption: tutorial-mpileaks/package.py (from tutorial/examples/packaging/1.package.py)

tutorial_stacks.rst

@@ -16,12 +16,11 @@ In this tutorial we will see how to use them to manage large deployments, a comm
 What usually characterizes these deployments, compared to a typical single-user environment, is the need to provide the same set of packages built against a variety of configurations: different MPI libraries, LAPACK implementations, or compilers.
 
 Below, we'll build a representative example of such a deployment.
-Our goal is to install ``netlib-scalapack`` against:
+Our goal is to install ``netlib-scalapack`` compiled with ``gcc@16``, which is newer than the system-provided ``gcc@15``, and linked against:
 
 - two MPI libraries (``openmpi`` and ``mpich``)
 - two LAPACK providers (``openblas`` and ``netlib-lapack``)
 
-and compiled with ``gcc@16``, which is newer than the system-provided ``gcc@15``.
 We'll also install ``py-scipy`` linked against ``openblas``.
 
 We'll first focus on how to configure and install the software correctly.
@@ -81,7 +80,7 @@ Spec groups offer a better tool: the ``override`` block, which scopes any Spack
    :language: yaml
    :emphasize-lines: 11-18,23-30
 
-Here we used it to set compiler preferences at the language level, once for each group:
+Here we used the ``override`` block to set compiler preferences at the language level, once for each group:
 
 1. The ``compiler`` group prefers ``gcc@15``
 2. The ``stack`` group prefers ``gcc@16``
@@ -284,7 +283,7 @@ Alternatively, to create a buildcache you can:
    $ spack gpg create <name> <e-mail>
    $ spack buildcache push ./mirror
 
-Don't forget to set an appropriate value for the padding of the install tree, see `how to setup relocation <https://spack.readthedocs.io/en/latest/binary_caches.html#relocation>`_ in our documentation.
+Don't forget to set an appropriate value for the padding of the install tree; see `how to set up relocation <https://spack.readthedocs.io/en/latest/binary_caches.html#relocation>`_ in our documentation.
 
 --------------------------
 Multiple Filesystem Views
@@ -374,7 +373,7 @@ Let's check the generated module files:
    :language: console
 
 The set of modules is already usable, and the hierarchy already works.
-For instance, we can load the ``gcc`` compiler and check that we have ``gcc`` in our path and a lot of modules available, all compiled with ``gcc@16``:
+For instance, we can load the ``gcc`` compiler and check that ``gcc`` is in our path and that many modules are available, all compiled with ``gcc@16``:
 
 .. literalinclude:: outputs/stacks/modules-3.out
    :language: console