remove packaging-related specs

Author: rickeylev

peps/pep-0796.rst

@@ -16,48 +16,41 @@ Post-History: `DD-MM-YYYY <https://url-to-pep-discussion>`__
 Abstract
 ========
 
-This PEP describes how a Python virtual environment can be configured
-to allow copying it as-is to different hosts and still have a functioning
-virtual environment. Making this work consists of two main pieces:
-
-* Using a relative path for ``home`` in ``pyvenv.cfg``, which Python canonicalizes
-  at runtime.
-* Having package installers recognize a relative venv and generate
-  appropriate outputs, e.g. script wrappers.
-
+This PEP describes how a relative path for ``home`` in a Python virtual
+environment's ``pyvenv.cfg`` is understood by the Python startup process.
+Specifically, how is it canonicalized into an absolute path later used
+by the runtime. This small detail is a fundamental building block for
+virtual environments to be more portable.
 
 Motivation
 ==========
 
-There are two main motivations for allowing relative paths in ``pyvenv.cfg``
-and thus enabling host-relocatable virtual environments.
+There are two main motivations for allowing relative paths in ``pyvenv.cfg``.
 
 First, it is currently proscribed that the ``home`` value in ``pyvenv.cfg`` be
 an absolute path. The behavior of relative paths is unspecified. While
 techniques exist to work around this for every other sub-part of a virtual
 environment, the one remaining part without a teneable solution is how the
 Python runtime itself finds ``PYTHONHOME``. This is because, currently, the
 startup process requires absolute paths be used for the ``home`` key in
-``pyvenv.cfg``. If a relative path is used, behavior is unspecified (currently,
-it is relative to the process's current working directory, making it untenable
-to use).
+``pyvenv.cfg``. If a relative path is used, behavior is unspecified (the
+current implementation ends up making it relative to the process's current
+working directory, making it untenable to use).
 
 This requirement is overly proscriptive and restrictive because, given a known
 anchor point, it's easy to tranform a relative path to an absolute path and
 still retain predictable and reliable behavior. Thus, the absolute path
 requirement should be relaxed and relative path behavior allowed and defined.
 
-Second, virtual environments are the standard way for running Python
-applications. This means ...
+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 means...
 
 * The closer the dev environment is to the non-dev environment, the more
-  reliable software one can get.
-* The closer the dev and non-dev envs are, the easier it is to reproduce
-  issues.
+  reliable software one can get, and the easier it is to reproduce issues.
 * The simpler the process is to re-create the environment, the more reliable
-  software one can get.
-* The simpler the process is to re-create the environment, the faster the
-  process can be.
+  software one can get, and the faster the process can be.
 
 By making it trivial to copy a virtual environment from one host to another, it
 avoids these categories of problems. Additionally, the development tools to
@@ -127,43 +120,15 @@ similar, which is a lower cognitive burden and helps avoids the question of
 This change is only a couple of lines in the start up code. Specifically, when
 parsing the ``pyvenv.cfg`` file and finding the ``home`` value, it just needs
 to be checked if it's already absolute. If not, then join to the directory name
-of the ``pyvenv.cfg`` file. The code alredy knows the directory and has helpers
-already present for checking if a path is absolute and joining two paths.
+of the ``pyvenv.cfg`` file. The code already knows the directory and has
+helpers already present for checking if a path is absolute and joining two
+paths.
 
 A proof-of-concept of this is implemented in
 `rickeylev/feat.relative.pyvenv.home <https://github.com/python/cpython/compare/main...rickeylev:cpython:feat.relative.pyvenv.home>`__
 
-Virtual Environment Tool Changes
-================================
-
-Virtual environment management tools should support a mechanism to generate a
-``pyvenv.cfg`` file with a ``home`` key that is a relative path to the relevant
-Python installation.
-
-For the standard library's ``venv`` module, the flag ``--relative`` will be
-added to trigger this behavior.
-
-Package Installer Changes
-=========================
-
-Package installers must be aware of when a relative virtual environment has
-been defined so they can avoid using absolute paths. The two main places
-absolute paths occur today are:
-
-1. ``bin/`` scripts, where shebangs are rewritten.
-2. ``site-packages`` symlinks.
-
-For symlinks, they should create relative symlinks pointing to the actual
-installation directory for packages.
-
-For ``bin/`` scripts, installers should generate executables that are able to
-locate the venv's interpreter at runtime. How to do this is implementation
-defined. Typically it means having shell code use ``$0`` to locate the
-appropriate ``bin/python3`` executable, but installers are free to use whatever
-mechanism they want (e.g. a native polyglot executable).
-
 Copying a Venv to Another Host
-=================================
+==============================
 
 Copying the venv to another host is simple: copy the venv directory itself, and
 any directories outside the venv it needs, while preserving the relative
@@ -202,7 +167,9 @@ A reference implementation is available by using the combination of:
 Open Issues
 ===========
 
-(todo: placeholder section to be updated after discussions)
+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
 =========
@@ -211,10 +178,6 @@ Footnotes
   host-relocatable virtual environments.
 * `rules_py <https://github.com/aspect-build/rules_py>`__: implements
   host-relocatable virtual environments.
-* `uv venv
-  relocatable
-  <https://docs.astral.sh/uv/reference/cli/#uv-venv--relocatable>`__:
-  implements same-host relocatable virtual environments.
 * `python-build-standalone <https://github.com/astral-sh/python-build-standalone>`__:
   A relocatable Python runtime.
 * `PoC for relative home in Python startup <https://github.com/python/cpython/compare/main...rickeylev:cpython:feat.relative.pyvenv.home>`__
@@ -227,9 +190,9 @@ Rejected Ideas
 Relative to virtual env root
 ----------------------------
 
-Having the ``home`` value in ``pyvenv.cfg`` relative to the virtual environments
-root directory would work just as well, but this idea is rejected because it
-requires additional effort to compute the virtual env root.
+Having the ``home`` value in ``pyvenv.cfg`` relative to the virtual
+environments root directory would work just as well, but this idea is rejected
+because it requires additional effort to compute the virtual env root.
 
 Unspecified home means to dynamically compute home
 ----------------------------------------------------