fix lint

Author: cmelone

tutorial_developer_workflows.rst

@@ -11,38 +11,38 @@
 Developer Workflows Tutorial
 ============================
 
-This tutorial will guide you through using the ``spack develop`` command to develop software from local source code within a Spack environment.  
+This tutorial will guide you through using the ``spack develop`` command to develop software from local source code within a Spack environment.
 With this command, Spack manages your dependencies while you focus on testing changes to your library and/or application.
 
 -----------------------------
 Installing from Local Source
 -----------------------------
 
-The ``spack install`` command typically fetches source code from a mirror or the internet before building and installing your package.  
+The ``spack install`` command typically fetches source code from a mirror or the internet before building and installing your package.
 As developers, however, we often want to build from local source code that we continuously modify, build, and test.
 
-Let's imagine we're working on ``scr``—a library used to implement scalable checkpointing in application codes.  
-It supports fast, efficient checkpoint read/write operations using MPI and high-bandwidth file I/O.  
+Let's imagine we're working on ``scr``—a library used to implement scalable checkpointing in application codes.
+It supports fast, efficient checkpoint read/write operations using MPI and high-bandwidth file I/O.
 We want to test changes to ``scr`` within an actual application, so we'll use ``macsio``, a proxy application that mimics typical HPC I/O workloads.
 
 We've chosen ``scr`` and ``macsio`` because they are both quick to build.
 
-We'll begin by creating a Spack environment for our development work.  
-We need to build ``macsio`` with ``scr`` support, and for now, we want everything built without Fortran support.  
+We'll begin by creating a Spack environment for our development work.
+We need to build ``macsio`` with ``scr`` support, and for now, we want everything built without Fortran support.
 Let's set up this development workflow:
 
 .. literalinclude:: outputs/dev/setup-scr.out
    :language: console
 
-Before making any changes, we verify that everything builds correctly.  
+Before making any changes, we verify that everything builds correctly.
 Spack builds the entire development tree as specified and links all components together for you.
 
 
 .. literalinclude:: outputs/dev/setup-scr.out
    :language: console
 
 
-Before making any changes, we verify that everything builds correctly.  
+Before making any changes, we verify that everything builds correctly.
 Spack builds the entire development tree as specified and links all components together for you.
 
 
@@ -100,17 +100,17 @@ Now we are ready to begin work on the actual application.
 Development Iteration Cycle
 -----------------------------
 
-Let's assume that ``scr`` has a bug, and we'd like to patch it to find out what the problem is.  
-First, we tell Spack that we want to check out the version of ``scr`` we intend to work on.  
+Let's assume that ``scr`` has a bug, and we'd like to patch it to find out what the problem is.
+First, we tell Spack that we want to check out the version of ``scr`` we intend to work on.
 In this case, it's the 3.1.0 release that we want to patch:
 
 .. literalinclude:: outputs/dev/develop-1.out
    :language: console
 
-The ``spack develop`` command marks the package as 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 is located.  
-The ``develop`` command also downloads or checks out the source code for the package.  
-By default, the source code is downloaded into a subdirectory of the environment.  
+The ``spack develop`` command marks the package as 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 is located.
+The ``develop`` command also downloads or 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:
@@ -133,55 +133,55 @@ Now that this is done, we tell Spack to rebuild both ``scr`` and ``macsio`` by r
 .. literalinclude:: outputs/dev/develop-2.out
    :language: console
 
-This rebuilds ``scr`` from the subdirectory we specified.  
-If your package uses CMake, Spack will build it in a directory corresponding to the hash of your package.  
+This rebuilds ``scr`` from the subdirectory we specified.
+If your package uses CMake, Spack will build it in a directory corresponding to the hash of your package.
 From there, you can change into the appropriate directory and perform your own build/test cycles.
 
-Now we can develop our code.  
-For the sake of this demo, we're going to intentionally introduce an error.  
+Now we can develop our code.
+For the sake of this demo, we're going to intentionally introduce an error.
 Let’s edit a file and remove the first semicolon we find.
 
 .. literalinclude:: outputs/dev/edit-1.out
    :language: console
 
-Once you have a development package, ``spack install`` works like ``make``.  
-Because Spack knows the source code directory of the package, it checks file timestamps to detect recent changes.  
+Once you have a development package, ``spack install`` works like ``make``.
+Because Spack knows the source code directory of the package, it checks file timestamps to detect recent changes.
 If any files have been modified, Spack will rebuild ``scr`` and its dependents.
 
 .. literalinclude:: outputs/dev/develop-3.out
    :language: console
 
-Here, the build failed as expected.  
-We can inspect the build output in ``scr/spack-build-out.txt``.  
+Here, the build failed as expected.
+We can inspect the build output in ``scr/spack-build-out.txt``.
 Alternatively, to debug interactively, we can launch a shell within the build environment using:
 
 ``spack build-env scr@2.0 -- bash``
 
-If that’s too much to remember, sourcing ``scr/spack-build-env.txt`` will set the appropriate environment variables so you can diagnose the build manually.  
+If that’s too much to remember, sourcing ``scr/spack-build-env.txt`` will set the appropriate environment variables so you can diagnose the build manually.
 Now let's fix the issue and rebuild directly.
 
 .. literalinclude:: outputs/dev/develop-4.out
    :language: console
 
 You'll notice that Spack rebuilt both ``scr`` and ``macsio``, as expected.
 
-Taking advantage of iterative builds with Spack requires cooperation from your build system.  
-When Spack performs a rebuild on a development package, it reruns all the build stages without cleaning the source and build directories to a pristine state.  
+Taking advantage of iterative builds with Spack requires cooperation from your build system.
+When Spack performs a rebuild on a development package, it reruns all the build stages without cleaning the source and build directories to a pristine state.
 If your build system can reuse previously compiled object files, you’ll benefit from an iterative build.
 
 - If your package uses ``make``, you should get iterative builds automatically when using ``spack develop``.
 - If your package uses CMake with the standard ``cmake`` / ``build`` / ``install`` stages, you'll also get iterative builds automatically.  
   This is because CMake doesn’t modify the file time of ``CMakeCache.txt`` unless your CMake flags change.
 - If your package uses Autoconf, rerunning the typical ``autoreconf`` stage will usually modify the timestamp of ``config.h``, which may trigger a full rebuild.
 
-Multiple packages can also be marked as development packages.  
+Multiple packages can also be marked as development packages.
 If we were co-developing ``macsio``, we could run:
 
 .. literalinclude:: outputs/dev/develop-5.out
    :language: console
 
-Using development workflows also allows us to share our full development setup with other team members.  
-They can simply use our ``spack.yaml`` to create a new environment and replicate the entire build process.  
+Using development workflows also allows us to share our full development setup with other team members.
+They can simply use our ``spack.yaml`` to create a new environment and replicate the entire build process.
 For example, here we create another development environment:
 
 .. literalinclude:: outputs/dev/otherdevel.out
@@ -198,15 +198,15 @@ When we're done developing, we simply tell Spack that it no longer needs to keep
 Workflow Summary
 -------------------
 
-Use the ``spack develop`` command within an environment to create a reproducible build setup for your development workflow.  
-Spack will manage all dependencies and link your packages together automatically.  
+Use the ``spack develop`` command within an environment to create a reproducible build setup for your development workflow.
+Spack will manage all dependencies and link your packages together automatically.
 Within a development environment, ``spack install`` behaves similarly to ``make``: it checks file timestamps and rebuilds only the minimum set of Spack packages required to reflect your changes.
 
 -------------------
 Optional: Tips and Tricks
 -------------------
 
-This section covers additional features that complement the core tutorial above.  
+This section covers additional features that complement the core tutorial above.
 Many of these tips are especially useful for specific projects and developer workflows.
 
 A list of available options for the ``spack develop`` command can be viewed below:
@@ -219,11 +219,11 @@ A list of available options for the ``spack develop`` command can be viewed belo
 Source Code Management
 ----------------------
 
-The ``spack develop`` command allows users to control the location of source code.  
+The ``spack develop`` command allows users to control the location of source code.
 By default, Spack manages source locations and handles cloning automatically, but software developers often prefer more control.
 
-You can specify the source directory using the ``--path`` argument when invoking ``spack develop``.  
-If the specified directory already exists, Spack will not attempt to fetch the source code.  
+You can specify the source directory using the ``--path`` argument when invoking ``spack develop``.
+If the specified directory already exists, Spack will not attempt to fetch the source code.
 This allows developers to pre-clone repositories or use preferred directory paths as needed.
 
 .. code-block:: console
@@ -238,10 +238,10 @@ This allows developers to pre-clone repositories or use preferred directory path
 Navigation and the Build Environment
 ------------------------------------
 
-Diving into the build environment was introduced earlier in the packaging section using the ``spack build-env scr -- bash`` command.  
+Diving into the build environment was introduced earlier in the packaging section using the ``spack build-env scr -- bash`` command.
 This is a helpful feature because it allows you to run commands inside the package’s build environment.
 
-In the packaging section, this was combined with ``spack cd`` to demonstrate a manual build process outside of Spack’s automated workflow.  
+In the packaging section, this was combined with ``spack cd`` to demonstrate a manual build process outside of Spack’s automated workflow.
 This approach is especially useful in developer environments, providing a streamlined workflow for iterating on a single package without the overhead of the ``spack install`` command.
 
 The extra features of the ``spack install`` command are often unnecessary when rapidly iterating between building and testing a specific package.
@@ -272,9 +272,8 @@ Working directly within the build environment, combined with Spack's navigation
 Combinatorics
 -------------
 
-The final topic in this tutorial highlights the power of combinatorial development builds.  
-There are many cases where developers want to see how a single set of changes affects multiple build configurations—for example:  
-``+cuda`` vs ``~cuda``, ``%gcc`` vs ``%clang``, or ``build_type=Release`` vs ``build_type=Debug``.
+The final topic in this tutorial highlights the power of combinatorial development builds.
+There are many cases where developers want to see how a single set of changes affects multiple build configurations—for example: ``+cuda`` vs ``~cuda``, ``%gcc`` vs ``%clang``, or ``build_type=Release`` vs ``build_type=Debug``.
 
 Developers can build all of these configurations with a single ``spack install`` call, as long as the develop spec is generic enough to cover the spec variations of the packages.
 
@@ -290,8 +289,7 @@ Developers can build all of these configurations with a single ``spack install``
 
 While we won't build out this example, it illustrates how the ``dev_path`` for both ``build_type=Release`` and ``build_type=Debug`` points to the same source code.
 
-If we want to do most of our incremental builds using the ``Release`` configuration and periodically check results using the ``Debug`` build, we can combine the workflow from the previous example:  
-First, enter the ``Release`` build environment using:
+If we want to do most of our incremental builds using the ``Release`` configuration and periodically check results using the ``Debug`` build, we can combine the workflow from the previous example: First, enter the ``Release`` build environment using:
 
 ``spack build-env scr build_type=Release -- bash``