Merge pull request #1340 from jeanas/pep440

Import PEP 440

source/glossary.rst

@@ -252,11 +252,10 @@ Glossary
     Version Specifier
 
        The version component of a :term:`Requirement Specifier`. For example,
-       the ">=1.3" portion of "foo>=1.3".  :pep:`440` contains
-       a :pep:`full specification
-       <440#version-specifiers>` of the
-       specifiers that Python packaging currently supports.  Support for PEP440
-       was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0.
+       the ">=1.3" portion of "foo>=1.3".  Read the :ref:`Version specifier specification
+       <version-specifiers>` for a full description of the
+       specifiers that Python packaging currently supports.  Support for this
+       specification was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0.
 
     Virtual Environment
 

source/specifications/binary-distribution-format.rst

@@ -182,8 +182,8 @@ this character cannot appear within any component. This is handled as follows:
   Tools consuming wheels must be prepared to accept ``.`` (FULL STOP) and
   uppercase letters, however, as these were allowed by an earlier version of
   this specification.
-- Version numbers should be normalised according to :pep:`440`. Normalised
-  version numbers cannot contain ``-``.
+- Version numbers should be normalised according to the :ref:`Version specifier
+  specification <version-specifiers>`. Normalised version numbers cannot contain ``-``.
 - The remaining components may not contain ``-`` characters, so no escaping
   is necessary.
 

source/specifications/core-metadata.rst

@@ -51,8 +51,9 @@ Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1",
 Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
 greater than the highest version they support, and MUST fail if
 ``metadata_version`` has a greater major version than the highest
-version they support (as described in :pep:`440`, the major version is the
-value before the first dot).
+version they support (as described in the
+:ref:`Version specifier specification <version-specifiers>`,
+the major version is the value before the first dot).
 
 For broader compatibility, build tools MAY choose to produce
 distribution metadata using the lowest metadata version that includes
@@ -94,7 +95,8 @@ Version
 .. versionadded:: 1.0
 
 A string containing the distribution's version number.  This
-field  must be in the format specified in :pep:`440`.
+field  must be in the format specified in the
+:ref:`Version specifier specification <version-specifiers>`.
 
 Example::
 
@@ -585,8 +587,8 @@ This field may be followed by an environment marker after a semicolon.
 
 Because they refer to non-Python software releases, version numbers
 for this field are **not** required to conform to the format
-specified in :pep:`440`:  they should correspond to the
-version scheme used by the external dependency.
+specified in the :ref:`Version specifier specification <version-specifiers>`:
+they should correspond to the version scheme used by the external dependency.
 
 Notice that there is no particular rule on the strings to be used.
 

source/specifications/declaring-project-metadata.rst

@@ -87,7 +87,8 @@ as it is read for internal consistency.
 - Corresponding :ref:`core metadata <core-metadata>` field:
   :ref:`Version <core-metadata-version>`
 
-The version of the project as supported by :pep:`440`.
+The version of the project, as defined in the
+:ref:`Version specifier specification <version-specifiers>`.
 
 Users SHOULD prefer to specify already-normalized versions.
 

source/specifications/dependency-specifiers.rst

@@ -16,8 +16,8 @@ acceptable, so the language permits describing all these cases.
 The language defined is a compact line based format which is already in
 widespread use in pip requirements files, though we do not specify the command
 line option handling that those files permit. There is one caveat - the
-URL reference form, specified in :pep:`440` is not actually
-implemented in pip, but since :pep:`440` is accepted, we use that format rather
+URL reference form, specified in :ref:`Versioning specifier specification <version-specifiers>`
+is not actually implemented in pip, but we use that format rather
 than pip's current native format.
 
 Specification
@@ -57,7 +57,8 @@ as comments, multiple line support via continuations, or other such features.
 The full grammar including annotations to build a useful parse tree is
 included at the end of this document.
 
-Versions may be specified according to the :pep:`440` rules. (Note:
+Versions may be specified according to the rules of the
+:ref:`Version specifier specification <version-specifiers>`. (Note:
 URI is defined in :rfc:`std-66 <3986>`)::
 
     version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
@@ -159,12 +160,13 @@ If multiple extras are listed, all the dependencies are unioned together.
 Versions
 --------
 
-See :pep:`440` for more detail on both version numbers and version
-comparisons. Version specifications limit the versions of a distribution that
-can be used. They only apply to distributions looked up by name, rather than
+See the :ref:`Version specifier specification <version-specifiers>` for
+more detail on both version numbers and version comparisons. Version
+specifications limit the versions of a distribution that can be
+used. They only apply to distributions looked up by name, rather than
 via a URL. Version comparison are also used in the markers feature. The
-optional brackets around a version are present for compatibility with :pep:`345`
-but should not be generated, only accepted.
+optional brackets around a version are present for compatibility with
+:pep:`345` but should not be generated, only accepted.
 
 Environment Markers
 -------------------
@@ -186,10 +188,11 @@ fixes some issues that were observed in the design described in :pep:`426`.
 
 Comparisons in marker expressions are typed by the comparison operator.  The
 <marker_op> operators that are not in <version_cmp> perform the same as they
-do for strings in Python. The <version_cmp> operators use the :pep:`440`
-version comparison rules when those are defined (that is when both
-sides have a valid version specifier). If there is no defined :pep:`440`
-behaviour and the operator exists in Python, then the operator falls back to
+do for strings in Python. The <version_cmp> operators use the version comparison
+rules of the :ref:`Version specifier specification <version-specifiers>`
+when those are defined (that is when both sides have a valid
+version specifier). If there is no defined behaviour of this specification
+and the operator exists in Python, then the operator falls back to
 the Python behaviour. Otherwise an error should be raised. e.g. the following
 will result in  errors::
 

source/specifications/direct-url-data-structure.rst

@@ -11,7 +11,7 @@ source trees, source distributions and wheels.
 
 The representation of the components of this data structure as a :rfc:`1738` URL
 is not formally specified at time of writing. A common representation is the pip URL
-format. Other examples are provided in :pep:`440`.
+format. Other examples are provided in the :ref:`Version specifier specification <version-specifiers>`.
 
 
 Specification

source/specifications/recording-installed-packages.rst

@@ -42,12 +42,11 @@ packages (commonly, the ``site-packages`` directory).
 
 This directory is named as ``{name}-{version}.dist-info``, with ``name`` and
 ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be
-normalized (see :ref:`name-normalization` and
-:pep:`PEP 440 <440#normalization>` for the definition of normalization for
-each field respectively), and replace dash (``-``) characters with
-underscore (``_``) characters, so the ``.dist-info`` directory always has
-exactly one dash (``-``) character in its stem, separating the ``name`` and
-``version`` fields.
+normalized (see the :ref:`name normalization specification <name-normalization>`
+and the :ref:`version normalization specification <version-specifiers-normalization>`),
+and replace dash (``-``) characters with underscore (``_``) characters,
+so the ``.dist-info`` directory always has exactly one dash (``-``) character in
+its stem, separating the ``name`` and ``version`` fields.
 
 Historically, tools have failed to replace dot characters or normalize case in
 the ``name`` field, or not perform normalization in the ``version`` field.