Dev workflow: no longer need to reconcretize

Signed-off-by: psakiev <psakiev@sandia.gov>

Author: psakievich

tutorial_developer_workflows.rst

@@ -138,28 +138,35 @@ Now we are ready to begin work on the actual application.
 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.
+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.
 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: spec
 
-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.
+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:
+
+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. This variant tells Spack where to find the source code for the spec.
+3. Calls to ``spack install`` will now use the source code at ``dev_path`` when building that package. 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 insitu and updates the ``spack.lock`` file unless the ``--no-modify-concrete-specs`` option is passed.
+If ``--no-modify-concrete-specs`` is passed, the environment is not yet concretized, or needs to be futher changed to satisfy the develop specs (i.e. change version of the package) then selection of develop specs and assignment of ``dev_path`` are handled by the concretizer.
+
+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.
+You can change the location of this source directory by modifying the ``path:`` attribute of the develop configuration in the environment or by passing the ``--path`` options when calling ``spack develop``.
 
 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 package so it can supply the correct flags for the package's build system.
-  If a version is not supplied, then Spack will take the maximum version defined in the package where `infinity versions <https://spack.readthedocs.io/en/latest/packaging_guide_creation.html#version-comparison>`_ like ``develop`` and ``main`` have a higher value than the numeric versions.
+* Spack needs to know the version of the dev package so it can supply the correct flags for the package's build system.
+  If a version is not supplied or detectable in the environment, then Spack falls back to the maximum version defined in the package where `infinity versions <https://spack.readthedocs.io/en/latest/packaging_guide_creation.html#version-comparison>`_ like ``develop`` and ``main`` have a higher value than the numeric versions.
 * You should ensure a spec for the package you are developing appears in the DAG of at least one of the roots of the environment with the same version that you are developing.
   ``spack add <package>`` with the matching version you want to develop is a way to ensure the develop spec is satisfied in the ``spack.yaml`` environments file.
   This is because develop specs are not concretization constraints but rather criteria for adding the ``dev_path=`` variant to existing spec.
-* You'll need to re-concretize the environment so that the version number and the ``dev_path=`` attributes are properly added to the cached spec in ``spack.lock``.
 
 .. literalinclude:: outputs/dev/develop-conc.out
    :language: console