Fix: Correct Spack capitalization in tutorial files.

This commit corrects the capitalization of "Spack" in all tutorial_*.rst files.

The changes ensure that:
- "Spack" is used when referring to the project or tool by name.
- "spack" is used when referring to the command-line executable.

Author: google-labs-jules[bot]

tutorial_advanced_packaging.rst

@@ -74,7 +74,7 @@ Set environment variables in dependent packages at build-time
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Dependencies can set environment variables that are required when their dependents build.
-For example, when a package depends on a python extension like py-numpy, Spack's ``python`` package will add it to ``PYTHONPATH`` so it is available at build time; this is required because the default setup that spack does is not sufficient for python to import modules.
+For example, when a package depends on a python extension like py-numpy, Spack's ``python`` package will add it to ``PYTHONPATH`` so it is available at build time; this is required because the default setup that Spack does is not sufficient for python to import modules.
 
 To provide environment setup for a dependent, a package can implement the
 :py:func:`setup_dependent_build_environment

tutorial_buildsystems.rst

@@ -238,7 +238,7 @@ If we look inside, we see that ``CC`` and ``CXX`` point to our GNU compiler:
 
 .. note::
     As usual make sure you have shell support activated with Spack:
-        ``source /path/to/spack_root/spack/share/spack/setup-env.sh``
+        ``source /path/to/spack_root/share/spack/setup-env.sh``
 
 .. code-block:: console
 

tutorial_configuration.rst

@@ -35,19 +35,19 @@ A partial list of some key configuration sections is provided below.
      - Naming, location and additional configuration of Spack generated modules
 
 The full list of sections can be viewed with ``spack config list``.
-For further education, we encourage you to explore the spack `documentation on configuration files <https://spack.readthedocs.io/en/latest/configuration.html#configuration-files>`_.
+For further education, we encourage you to explore the Spack `documentation on configuration files <https://spack.readthedocs.io/en/latest/configuration.html#configuration-files>`_.
 
 The principle goals of this section of the tutorial are:
 
 1. Introduce the configuration sections and scope hierarchy
 2. Demonstrate how to manipulate configurations
-3. Show how to configure system assets with spack (compilers and packages)
+3. Show how to configure system assets with Spack (compilers and packages)
 
 As such, we will primarily focus on the ``compilers`` and ``packages`` configuration sections in this portion of the tutorial.
 
 We will explain this by first covering how to manipulate configurations from the command line and then show how this impacts the configuration file hierarchy.
 We will then move into compiler and package configurations to help you develop skills for getting the builds you want on your system.
-Finally, we will give some brief attention to more generalized spack configurations in the ``config`` section.
+Finally, we will give some brief attention to more generalized Spack configurations in the ``config`` section.
 
 For all of these features, we will demonstrate how we build up a full configuration file.
 For some, we will then demonstrate how the configuration affects the install command, and for others we will use the ``spack spec`` command to demonstrate how the configuration changes have affected Spack's concretization algorithm.
@@ -81,7 +81,7 @@ If we rerun ``spack config blame concretizer`` we can see that the change was ap
    $ spack config blame concretizer
 
 Notice that the reference file for this option is now different.
-This indicates the scope where the configuration was set in, and we will discuss how spack chooses the default scope shortly.
+This indicates the scope where the configuration was set in, and we will discuss how Spack chooses the default scope shortly.
 For now, it is important to note that the ``spack config`` command accepts an optional ``--scope`` flag so we can be more precise in the configuration process.
 This will make more sense after the next section which provides the definition of Spack's configuration scopes and their hierarchy.
 
@@ -485,7 +485,7 @@ Because of the configuration scoping we discussed earlier, this overrides the de
 Variant preferences
 ^^^^^^^^^^^^^^^^^^^
 
-As we've seen throughout this tutorial, HDF5 builds with MPI enabled by default in Spack.
+As we'veseen throughout this tutorial, HDF5 builds with MPI enabled by default in Spack.
 If we were working on a project that would routinely need serial HDF5, that might get annoying quickly, having to type ``hdf5~mpi`` all the time.
 Instead, we'll update our preferences for HDF5.
 
@@ -813,3 +813,5 @@ For more detailed documentation on Spack's many configuration settings, see `the
 
 For examples of how other sites configure Spack, see https://github.com/spack/spack-configs.
 If you use Spack at your site and want to share your config files, feel free to submit a pull request!
+
+[end of tutorial_configuration.rst]

tutorial_developer_workflows.rst

@@ -11,7 +11,7 @@
 Developer Workflows Tutorial
 ============================
 
-This tutorial will guide you through the process of using the ``spack develop`` command to develop software from local source code within a spack environment.
+This tutorial will guide you through the process of using the ``spack develop`` command to develop software from local source code within a Spack environment.
 With this command, Spack will manage your dependencies while you focus on testing changes to your library and/or application.
 
 
@@ -139,19 +139,19 @@ Development iteration cycles
 -----------------------------
 
 Let's assume that scr has a bug, and we'd like to patch scr to find out what the problem is.
-First, we tell spack that we'd like to check out the version of scr that we want to work on.
+First, we tell Spack that we'd like to check out the version of scr that we want to work on.
 In this case, it will be the 3.1.0 release that we want to write a patch for:
 
 .. literalinclude:: outputs/dev/develop-1.out
    :language: console
 
-The spack develop command marks the package as being a "development" package in the ``spack.yaml``.
+The ``spack develop`` command marks the package as being a "development" package in the ``spack.yaml``.
 This adds a special ``dev_path=`` attribute to the spec for the package, so Spack remembers where the source code for this package is located.
 The develop command also downloads/checks out the source code for the package.
 By default, the source code is downloaded into a subdirectory of the environment.
 You can change the location of this source directory by modifying the ``path:`` attribute of the develop configuration in the environment.
 
-There are a few gotchas with the spack develop command
+There are a few gotchas with the ``spack develop`` command
 
 * You often specify the package version manually when specifying a
   package as a dev package. Spack needs to know the version of the dev
@@ -233,7 +233,7 @@ For example, we'll make another development environment here.
 
 Here, ``spack develop`` with no arguments will check out or download the source code and place it in the appropriate places.
 
-When we're done developing, we simply tell spack that it no longer needs to keep a development version of the package.
+When we're done developing, we simply tell Spack that it no longer needs to keep a development version of the package.
 
 .. literalinclude:: outputs/dev/wrapup.out
    :language: console
@@ -328,3 +328,5 @@ While we won't build out this example it illustrates how the ``dev_path`` for ``
 Now if we want to do most of our incremental builds using the ``Release`` build and periodically check the results using the ``Debug`` build we can combine the workflow from the previous example: dive into the ``Release`` versions build environment using ``spack build-env scr build_type=Release -- bash`` and navigate with ``spack cd -b scr build_type=Release``.
 Note that since there are two ``scr`` specs in the environment we must distinguish which one we want for these commands.
 When we are ready to check our changes for the debug build, we can exit out of the build environment subshell, rerun ``spack install`` to rebuild everything, and then inspect the debug build through our method of choice.
+
+[end of tutorial_developer_workflows.rst]

tutorial_environments.rst

@@ -749,3 +749,5 @@ Finding examples of environments
 
 * `Spack Stack Catalog <https://spack.github.io/spack-stack-catalog/>`_: for
   discovering environments that you can explore on GitHub
+
+[end of tutorial_environments.rst]

tutorial_modules.rst

@@ -65,7 +65,7 @@ Now we can re-source the setup file, and Spack modules will be put in our module
 
 .. code-block:: console
 
-  $ . spack/share/spack/setup-env.sh
+  $ . share/spack/setup-env.sh
 
 .. FIXME: this needs bootstrap support for ``lmod``
 
@@ -987,3 +987,5 @@ Since it is currently the default compiler (our current default is the most rece
   $ spack compiler rm gcc@12.3.0
 
 This will ensure the rest of the tutorial goes smoothly for you.
+
+[end of tutorial_modules.rst]

tutorial_packaging.rst

@@ -692,3 +692,5 @@ Making a package externally detectable
 * `Making a package externally discoverable
   <https://spack.readthedocs.io/en/latest/packaging_guide.html#making-a-package-discoverable-with-spack-external-find>`_:
   for making a package discoverable using the ``spack external find`` command
+
+[end of tutorial_packaging.rst]