PEP 665: try to use more specific terminology

Based on feedback from the Discourse thread.

Author: brettcannon

pep-0665.rst

@@ -37,24 +37,43 @@ projects:
 #. Specifying (at least) specific versions of dependencies for
    reproducible installations
 
-Both needs are important for various reasons. One is that without a
-complete listing of all dependencies and the specific versions to use,
-there can be a skew between developers of the same project, or
-developer and user, based on what versions of a project's dependencies
-happen to be available at the time of installation. For instance,
-a dependency may have v1 as the newest version on Monday when one
-developer installed the dependency, while v2 comes out on Wednesday
-when another developer installs the same dependency. Now the two
-developers are working against two different versions of the same
-dependency, which can lead to different outcomes.
+Both needs can be important for various reasons when creating a new
+environment. Consider a project which
+is an application that is deployed somewhere (either to users as a
+desktop app or to a server). Without a complete listing of all
+dependencies and the specific versions to use, there can be a skew
+between developers of the same project, or developer and user, based on
+what versions of a project's dependencies happen to be available at the
+time of installation in a new environment. For instance, a dependency may
+have v1 as the newest version on Monday when one developer installed the
+dependency, while v2 comes out on Wednesday when another developer
+installs the same dependency. Now the two developers are working against
+two different versions of the same dependency, which can lead to different
+outcomes. This is the use-case of developing a desktop or server
+application where one might have a ``requirements.txt`` file which
+specifies exact versions of various packages.
 
 Another important reason for reproducible installations is for
 security purposes. Guaranteeing that the same binary data is
-downloaded and installed for all installations makes sure that no bad
-actor has somehow changed a dependency's binary data in a malicious
+downloaded and installed for all installations of an app makes sure that no
+bad actor has somehow changed a dependency's binary data in a malicious
 way. A lock file can assist in this guarantee by recording the exact
 details of what should be installed and how to verify that those
-dependencies have not changed any bytes unexpectedly.
+dependencies have not changed any bytes unexpectedly. This is the use-case
+of developing a secure application using a ``requirements.txt`` file which
+specifies the hash of all the packages that should be installed.
+
+Tied into this concept of reproducibility is the speed at which an
+environment can be recreated. If you created a lock file as part of
+your local development, it can be used to speed up recreating that
+development environment by minimizing having to query the network or the
+scope of the possible resolution of dependencies. This makes recreating
+your local development environment faster as the amount of work required
+to calculate what dependencies to install has been minimized. This is the
+use-case of when you are working on a library or some such project where
+the lock file is not committed to version control and the lock file used as
+a local cache of installation resolution details, such as an uncommitted
+``poetry.lock`` file.
 
 The community itself has also shown a need for lock files based on the
 fact that multiple tools have independently created their own lock
@@ -75,9 +94,10 @@ of those communities include:
 #. Rust_
 
 
-Below, we identify various use-cases applicable to stakeholders in the
+Below, we identify some use-cases applicable to stakeholders in the
 Python community and anyone who interacts with Python package
-installers who are the ultimate consumers of a lock file.
+installers who are the ultimate consumers of a lock file (this is not
+considered exhaustive and is borrowed from PEP 650).
 
 
 ---------
@@ -284,6 +304,11 @@ Non-Goals
 Because of the expected size of lock files, no effort was put into
 making lock files *human-writable*.
 
+This PEP makes no attempt to make this work in any special way for
+installers to use a lock file to install into a *preexisting* environment.
+The assumption is the installer is installing into a *new/fresh*
+environment.
+
 
 =============
 Specification