Replace some PEP references with internal references

Use internal references when the PEPs have been imported into the PUG.

source/discussions/deploying-python-applications.rst

@@ -117,13 +117,14 @@ Unix (including Linux and macOS)
 pex
 ^^^
 
-`pex <https://pypi.org/project/pex/>`__ is  a library for generating .pex
-(Python EXecutable) files which are executable Python environments in the
-spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441`
-and makes the deployment of Python applications as simple as cp. pex files may
-even include multiple platform-specific Python distributions, meaning that a
-single pex file can be portable across Linux and macOS. pex is released under the
-Apache License 2.0.
+`pex <https://pypi.org/project/pex/>`__ is a library for generating .pex
+(Python EXecutable) files which are executable Python environments in
+the spirit of virtualenvs. pex is an expansion upon the ideas found in
+:ref:`zipapps <python:zipapp>` and makes the deployment of Python
+applications as simple as cp. pex files may even include multiple
+platform-specific Python distributions, meaning that a single pex file
+can be portable across Linux and macOS. pex is released under the Apache
+License 2.0.
 
 Configuration management
 ========================

source/glossary.rst

@@ -131,10 +131,13 @@ Glossary
         packaged into a :term:`Distribution <Distribution Package>`.
 
         Since most projects create :term:`Distributions <Distribution Package>`
-        using either :pep:`518` ``build-system``, :ref:`distutils` or
-        :ref:`setuptools`, another practical way to define projects currently
-        is something that contains a :term:`pyproject.toml`, :term:`setup.py`,
-        or :term:`setup.cfg` file at the root of the project source directory.
+        using a :term:`build backend` specified in the :ref:`[build-system] table
+        <pyproject-guide-build-system-table>` of their ``pyproject.toml`` file
+        (or the deprecated practice of having no ``pyproject.toml`` but either
+        ``setup.cfg`` or ``setup.py``), another practical way to define projects
+        currently is something that contains a :term:`pyproject.toml`,
+        :term:`setup.cfg`, or :term:`setup.py` file at the root of the project
+        source directory.
 
         Python projects must have unique names, which are registered on
         :term:`PyPI <Python Package Index (PyPI)>`. Each project will then
@@ -182,7 +185,7 @@ Glossary
     pyproject.toml
 
         The tool-agnostic :term:`Project` specification file.
-        Defined in :pep:`518`.
+        See :ref:`writing-pyproject-toml`.
 
     Release
 

source/guides/packaging-namespace-packages.rst

@@ -63,7 +63,7 @@ There are currently two different approaches to creating namespace packages,
 from which the latter is discouraged:
 
 #. Use `native namespace packages`_. This type of namespace package is defined
-   in :pep:`420` and is available in Python 3.3 and later. This is recommended if
+   is available in Python 3.3 and later. This is recommended if
    packages in your namespace only ever need to support Python 3 and
    installation via ``pip``.
 #. Use `legacy namespace packages`_. This comprises `pkgutil-style namespace packages`_
@@ -72,10 +72,10 @@ from which the latter is discouraged:
 Native namespace packages
 -------------------------
 
-Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is
-required to create a native namespace package is that you just omit
-:file:`__init__.py` from the namespace package directory. An example file
-structure (following :ref:`src-layout <setuptools:src-layout>`):
+Python 3.3 added **implicit** namespace packages. All that is required
+to create a native namespace package is that you just omit
+:file:`__init__.py` from the namespace package directory. An example
+file structure (following :ref:`src-layout <setuptools:src-layout>`):
 
 .. code-block:: text
 
@@ -155,7 +155,7 @@ the `native namespace package example project`_.
 Legacy namespace packages
 -------------------------
 
-These two methods, that were used to create namespace packages prior to :pep:`420`,
+These two methods, that were used to create namespace packages prior to Python 3.3,
 are now considered to be obsolete and should not be used unless you need compatibility
 with packages already using this method. Also, :doc:`pkg_resources <setuptools:pkg_resources>`
 has been deprecated.

source/key_projects.rst

@@ -102,7 +102,7 @@ not only provides features that plain :ref:`distutils` doesn't offer
 also provides a consistent build interface and feature set across all
 supported Python versions.
 
-Consequently, :ref:`distutils` was deprecated in Python 3.10 by :pep:`632` and
+Consequently, :ref:`distutils` was deprecated in Python 3.10 (by :pep:`632`) and
 has been :doc:`removed <python:whatsnew/3.12>` from the standard library in
 Python 3.12.  Setuptools bundles the standalone copy of distutils, and it is
 injected even on Python < 3.12 if you import setuptools first or use pip.
@@ -523,7 +523,7 @@ pdm
 `PyPI <https://pypi.org/project/pdm>`__
 
 PDM is a modern Python package manager. It uses :term:`pyproject.toml` to store
-project metadata as defined in :pep:`621`.
+project metadata in the :ref:`[project] table <pyproject-project-table>`.
 
 .. _pex:
 
@@ -664,8 +664,8 @@ shiv
 `GitHub <https://github.com/linkedin/shiv>`__ |
 `PyPI <https://pypi.org/project/shiv/>`__
 
-shiv is a command line utility for building fully self contained
-Python zipapps as outlined in :pep:`441`, but with all their
+shiv is a command line utility for building fully self contained Python
+:doc:`zipapps <python:library/zipapp>`, with all their
 dependencies included. Its primary goal is making distributing Python
 applications and command line tools fast & easy.
 

source/specifications/entry-points.rst

@@ -106,10 +106,10 @@ Within a value, readers must accept and ignore spaces (including multiple
 consecutive spaces) before or after the colon, between the object reference and
 the left square bracket, between the extra names and the square brackets and
 colons delimiting them, and after the right square bracket. The syntax for
-extras is formally specified as part of :pep:`508` (as ``extras``) and
-restrictions on values specified in :pep:`685`.
-For tools writing the file, it is recommended only to insert a space between the
-object reference and the left square bracket.
+extras is formally specified in the :ref:`dependency specifier specification
+<dependency-specifiers>` (as ``extras``) and restrictions on values specified
+in :pep:`685`. For tools writing the file, it is recommended only to insert a space
+between the object reference and the left square bracket.
 
 For example::
 

source/specifications/pyproject-toml.rst

@@ -352,28 +352,26 @@ be ambiguous in the face of ``[project.scripts]`` and
 ``dependencies``/``optional-dependencies``
 ------------------------------------------
 
-- TOML_ type: Array of :pep:`508` strings (``dependencies``), and a
-  table with values of arrays of :pep:`508` strings
-  (``optional-dependencies``)
+- TOML_ type: Array of strings (``dependencies``), and a
+  table with values of arrays of strings (``optional-dependencies``)
 - Corresponding :ref:`core metadata <core-metadata>` field:
   :ref:`Requires-Dist <core-metadata-requires-dist>` and
   :ref:`Provides-Extra <core-metadata-provides-extra>`
 
 The (optional) dependencies of the project.
 
-For ``dependencies``, it is a key whose value is an array of strings.
-Each string represents a dependency of the project and MUST be
-formatted as a valid :pep:`508` string. Each string maps directly to
-a :ref:`Requires-Dist <core-metadata-requires-dist>` entry.
-
-For ``optional-dependencies``, it is a table where each key specifies
-an extra and whose value is an array of strings. The strings of the
-arrays must be valid :pep:`508` strings. The keys MUST be valid values
-for :ref:`Provides-Extra <core-metadata-provides-extra>`. Each value
-in the array thus becomes a corresponding
-:ref:`Requires-Dist <core-metadata-requires-dist>` entry for the
-matching :ref:`Provides-Extra <core-metadata-provides-extra>`
-metadata.
+For ``dependencies``, it is a key whose value is an array of strings.  Each
+string represents a dependency of the project and MUST be formatted as a valid
+:ref:`dependency specifier <dependency-specifiers>`.  Each string maps directly
+to a :ref:`Requires-Dist <core-metadata-requires-dist>` entry.
+
+For ``optional-dependencies``, it is a table where each key specifies an extra
+and whose value is an array of strings. The strings of the arrays must be valid
+:ref:`dependency specifiers <dependency-specifiers>`.  The keys MUST be valid
+values for :ref:`Provides-Extra <core-metadata-provides-extra>`.  Each value in
+the array thus becomes a corresponding :ref:`Requires-Dist
+<core-metadata-requires-dist>` entry for the matching :ref:`Provides-Extra
+<core-metadata-provides-extra>` metadata.