Apply suggestions from code review

Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>

Author: rickeylev

peps/pep-0796.rst

@@ -43,7 +43,7 @@ requirement should be relaxed and relative path behavior allowed and defined.
 Second, such relative paths are a building block to enable portable virtual
 environments, i.e. copying a virtual environment as-is between hosts of
 compatible platforms. Portable venvs are appealing because virtual environments
-are the standard way for running Python applications. This provides several
+are a popular mechanism for running Python applications. This provides several
 benefits:
 
 * The closer the development environment is to the non-development environment,
@@ -52,14 +52,16 @@ benefits:
 * The simpler the process of re-creating the environment, the more reliable
   software can be achieved, and the faster the process can be.
 
-Making it trivial to copy a virtual environment from one host to another avoids
+Making it simpler to copy a virtual environment from one host to another mitigates
 these categories of problems. Additionally, the development tools to create a
 virtual environment and install its dependencies aren't needed on the host that
 intends to run the program.
 
-Because the virtual environment doesn't require modifications to be usable, it
+When the virtual environment doesn't require modifications to be usable, it
 also allows more advanced deployment mechanisms, e.g. remote mounting and
-caching of artifacts.
+caching of artifacts. While this PEP on its own isn't sufficient to enable that, it
+allows tools like `bazel` or `venvstacks` to more easily prepare constrained
+environments that allow for such use cases.
 
 Rationale
 =========
@@ -71,6 +73,11 @@ customizing how it's computed. Without the ability to specify where the
 supporting Python runtime files are, the interpreter can't finish startup,
 so other hook points (e.g. ``site`` initialization) never trigger.
 
+Tools that currently look to enable virtual environment portability across machines do
+so either by relying on undocumented interpreter behaviour (`bazel`, omitting the `home`
+key entirely to trigger an implementation dependent fallback to resolving via a symlinked
+interpreter binary on non-Windows systems) or by requiring a post-installation script to
+be executed after the environment is placed in its target location (`venvstacks`).
 Specification
 =============
 
@@ -97,10 +104,10 @@ For example, given
 i.e. it's equivalent to using that value verbatim in ``pyvenv.cfg``.
 
 
-Python Runtime Changes
+CPython Runtime Changes
 ======================
 
-The Python runtime itself *almost* already supports relative paths. The
+The CPython runtime itself *almost* already supports relative paths. The
 primitives are there, so the only change needed is to define how it resolves
 relative paths for ``home`` in ``pyvenv.cfg``.
 
@@ -130,9 +137,19 @@ A proof-of-concept of this is implemented in
 Backwards Compatibility
 =======================
 
-Because relative paths for ``home`` aren't usable in practice, and their
-behavior is undocumented and unspecified, there shouldn't be any backward
-compatibility concerns.
+
+Tools that work around the absolute `home` key limitation the way `bazel` and `venvstacks`
+currently do (omitting the `home` key, or editing it after moving the environment) will be
+unaffected.
+
+While the PEP author and sponsor aren't aware of any projects that work around the limitation
+by carefully controlling the current working directory used to launch the deployed Python
+environments on target systems, any such projects would be unaffected if they already ensured
+the working directory was set to the folder containing `pyvenv.cfg` (which seems like a plausible
+choice, since that is typically the root directory of the virtual environment). In the even more
+unlikely case where that assumption doesn't hold, tools generating relative virtual environment
+paths will typically be aware of the underlying base runtime Python version, and hence able to
+update the emitted relative path accordingly.
 
 
 How to Teach This
@@ -158,14 +175,15 @@ This PEP does not specify how to create a ``pyvenv.cfg`` with a relative path,
 nor how downstream tools (e.g. installers) should identify them or process
 them. These questions are best addressed separately by tool owners.
 
-Footnotes
+References
 =========
 
 * `rules_python <https://github.com/bazel-contrib/rules_python>`__: implements
   host-relocatable virtual environments.
 * `rules_py <https://github.com/aspect-build/rules_py>`__: implements
   host-relocatable virtual environments.
 * `python-build-standalone <https://github.com/astral-sh/python-build-standalone>`__:
+* `venvstacks <https://pypi.org/project/venvstacks/>`__: a tool for creating reproducible distribution artifacts from virtual environments
   A relocatable Python runtime.
 * `PoC for relative home in Python startup <https://github.com/python/cpython/compare/main...rickeylev:cpython:feat.relative.pyvenv.home>`__
 * `Python Ideas "Making venvs relocatable friendly" discussion <https://discuss.python.org/t/making-venvs-relocatable-friendly/96177>`__
@@ -189,7 +207,8 @@ dynamically compute it by checking if the current executable (which is
 typically the venv's ``bin/python3`` symlink) is a symlink and, if so, use
 where that points as ``PYTHONHOME``.
 
-This behavior is undesirable for a couple reasons:
+While currently used as a workaround by some tools, *standardising* this behavior
+is undesirable for a couple reasons:
 
 1. It presents platform-specific issues, namely with Windows. Windows does
    support symlinks, but not by default, and it can require special