typos / style

tutorial_configuration.rst

@@ -55,7 +55,7 @@ Configuration from the command line
 -----------------------------------
 
 You can run ``spack config blame [section]`` at any point in time to see what your current configuration is.
-If you omit the section, then spack will dump all the configurations settings to your screen.
+If you omit the section, then Spack will dump all the configuration settings to your screen.
 Let's go ahead and run this for the ``concretizer`` section.
 
 .. code-block:: console
@@ -248,7 +248,7 @@ We can do this by adding creating a toolchain config:
      - spec: '%[email protected]'
        when: '%fortran'
 
-We are essentially saying "use Clang for c/c++, and use GCC for Fortran".
+We are essentially saying "use Clang for C/C++, and use GCC for Fortran".
 You can use this new entry like so:
 
 .. code-block:: spec

tutorial_developer_workflows.rst

@@ -147,7 +147,7 @@ In this case, it will be the 2.0.0 release that we want to write a patch for:
 
 The ``spack develop`` command marks the package as being a "development" package based on the supplied ``develop spec``.
 Develop specs are listed in their own ``develop`` section inside the ``spack.yaml``.
-The mechanics of how this section is used to enforce develpoment are as follows:
+The mechanics of how this section is used to enforce development are as follows:
 
 1. Specs in the environment that ``satisfy`` the develop specs are selected for development.
 2. Any specs selected in step 1 receive a ``dev_path=`` variant.
@@ -156,8 +156,8 @@ The mechanics of how this section is used to enforce develpoment are as follows:
 3. Calls to ``spack install`` will now use the source code at ``dev_path`` when building that package.
 4. Spack doesn't clean this build up after a successful build so subsequent calls to ``spack install`` trigger incremental builds.
 
-If the environment is already concretized ``spack develop`` performs step 1 and 2 in situ and updates the ``spack.lock`` file by default.
-If the environment is not yet concretized the selection of develop specs and assignment of ``dev_path`` are handled during concretization.
+If the environment is already concretized, ``spack develop`` performs step 1 and 2 in situ and updates the ``spack.lock`` file by default.
+If the environment is not yet concretized, the selection of develop specs and assignment of ``dev_path`` are handled during concretization.
 
 So how does Spack determine the value of the ``dev_path`` variant?
 By default, the source code is downloaded into a subdirectory of the environment using Spack's staging functionality.
@@ -235,7 +235,7 @@ So far all of our calls to ``spack develop`` have been on a concretized environm
 If we don't want Spack to update the concrete environment's specs we can pass the ``---no-modify-concrete-spec``.
 Using ``---no-modify-concrete-spec`` will require you to force concretize an environment to have the develop specs take affect.
 
-There are a limited set of use-cases where one might want to use this option.
+There is a limited set of use-cases where one might want to use this option.
 Some example cases include:
 
 - Updating a develop spec before updating the environment to change a variant or version

tutorial_environments.rst

@@ -181,7 +181,7 @@ Using Packages
 Spack environments provide a convenient way to use your installed packages by automatically making them available in your shell environment.
 This is accomplished through a feature called **environment views**.
 
-An environment view is a directory structure mirroring a standard linux root filesystem with directories like ``/bin`` and ``/usr`` that contain symbolic links to all the packages installed in your Spack environment.
+An environment view is a directory structure mirroring a standard Linux root filesystem with directories like ``/bin`` and ``/usr`` that contain symbolic links to all the packages installed in your Spack environment.
 When you activate an environment with ``spack env activate``, Spack automatically:
 
 * Prepends the view's ``bin`` directory to your ``PATH`` environment variable

tutorial_modules.rst

@@ -13,7 +13,7 @@ Module Files Tutorial
 This tutorial illustrates how Spack can be used to generate module files for the software that has been installed.
 Both hierarchical and non-hierarchical deployments will be discussed in detail and we will show how to customize the content and naming of each module file.
 
-At the end of the tutorial readers should have a clear understanding of:
+At the end of the tutorial, readers will have a clear understanding of:
 
 * What module files are and how they are used on HPC clusters
 * How Spack generates module files for the software it installs
@@ -178,7 +178,7 @@ For further details we refer to its `documentation <https://modules.readthedocs.
 """"
 Lmod
 """"
-Lmod is a module system written in Lua, originally created  at the "Texas Advanced Computing Center" (TACC) by Robert McLay.
+Lmod is a module system written in Lua, originally created at the Texas Advanced Computing Center (TACC) by Robert McLay.
 You can get it with:
 
 .. code-block:: spec
@@ -210,7 +210,7 @@ Modules vs ``spack load``
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You may have noticed that we used ``spack load`` in the :ref:`module_file_tutorial_prerequisites` section above.
-This is a built-in mechanism of Spack's -- it's designed so that users on a cluster or a laptop can quickly get a package into their path, and it understands Spack's spec syntax.
+This is a built-in mechanism of Spack -- it's designed so that users on a cluster or a laptop can quickly get a package into their path, and it understands Spack's spec syntax.
 It does *not* require modules, as Spack needs to work regardless of whether modules are set up on the system.
 
 As you might expect, you can see what is loaded via ``spack load`` using ``spack find``:
@@ -411,7 +411,7 @@ If you try to regenerate the module files now you will get an error:
 .. note::
    We try to check for errors up front!
 
-   In Spack we check for errors upfront whenever possible, so don't worry about your module files: as a name clash was detected nothing has been changed on disk.
+   In Spack we check for errors up front whenever possible, so don't worry about your module files: as a name clash was detected nothing has been changed on disk.
 
 The problem here is that without the hashes the four different flavors of ``netlib-scalapack`` map to the same module file name.
 We can change how the names are formatted to differentiate them:
@@ -859,7 +859,7 @@ Extend the default templates
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Let's assume one of our software is protected by group membership: allowed users belong to the same Linux group, and access is granted at the group level.
-Wouldn't it be nice if people that are not yet entitled to use it could receive a helpful message at module load time that tells them who to contact in your organization to be inserted in the group?
+Wouldn't it be nice if people who are not yet entitled to use it could receive a helpful message at module load time that tells them who to contact in your organization to be inserted in the group?
 
 To automate the generation of module files with such site-specific behavior we'll start by extending the list of locations where Spack looks for module files.
 Let's create the file ``${SPACK_ROOT}/etc/spack/config.yaml`` with the content:

tutorial_packaging.rst

@@ -301,7 +301,7 @@ Our options for proceeding are:
 Reviewing the Build Log
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-The build log might yield some clues so let's look at the contents of the ``spack-build-out.txt`` file at the path recommended above by our failed installation:
+The build log might yield some clues, so let's look at the contents of the ``spack-build-out.txt`` file at the path recommended above by our failed installation:
 
 .. literalinclude:: outputs/packaging/build-output.out
    :language: console
@@ -617,7 +617,7 @@ Spack has thousands of built-in packages that can serve as examples to guide the
 Multiple Build Systems
 ----------------------
 
-There are cases where software actively supports two build systems; changes build systems as it evolves; or needs different build systems on different platforms.
+There are cases where software actively supports two build systems, changes build systems as it evolves, or needs different build systems on different platforms.
 Spack allows you to write a single, concise recipe for these cases that generally require minor changes to the package structure.
 
 Let's take a look at a *simplified* package for ``uncrustify``, which is a source code beautifier.

tutorial_stacks.rst

@@ -181,7 +181,7 @@ Reusable definitions
 So far, we have seen how we can use spec matrices to generate cross-product specs from rows containing a list of constraints.
 A common situation you will encounter with large deployments is the necessity to add multiple matrices to the list of specs, that possibly share some of those rows.
 
-To reduce the amount of duplication needed in the manifest file, and thus the maintenance burden for people maintaining it, Spack allows to *define* lists of constraints under the ``definitions`` attribute, and expand them later when needed.
+To reduce the amount of duplication needed in the manifest file, and thus the maintenance burden, Spack allows to *define* lists of constraints under the ``definitions`` attribute, and expand them later when needed.
 Let's rewrite our manifest accordingly:
 
 .. literalinclude:: outputs/stacks/examples/3.spack.stack.yaml
@@ -220,7 +220,7 @@ Conditional definitions
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Spec list definitions can also be conditioned on a ``when`` clause.
-The ``when`` clause is a python conditional that is evaluated in a restricted environment.
+The ``when`` clause is a Python conditional that is evaluated in a restricted environment.
 The variables available in ``when`` clauses are:
 
 ================= ===========