PEP 643: Further updates (GH-1700)

pep-0643.rst

@@ -77,6 +77,10 @@ a sdist, and the corresponding values in wheels built from that sdist.
 It requires build backends to clearly mark any fields which will *not*
 simply be copied unchanged from the sdist to the wheel.
 
+In addition, this PEP makes the `PyPA Specifications`_ document the
+canonical location for the specification of the sdist format (collecting
+the information in :pep:`517` and in this PEP).
+
 A new field, ``Dynamic``, will be added to the `Core Metadata Specification`_.
 This field will be multiple use, and will be allowed to contain the name
 of another core metadata field. The ``Dynamic`` metadata item is only
@@ -94,21 +98,15 @@ MUST NOT be present in the wheel.
 Build backends MUST ensure that these rules are followed, and MUST
 report an error if they are unable to do so.
 
-The following fields MAY NOT be marked as ``Dynamic``:
+The following fields are the only ones allowed to be marked as ``Dynamic``:
 
-* ``Name``
-* ``Version``
-* ``Summary``
-* ``Description``
-* ``Requires-Python``
-* ``License``
-* ``Author``
-* ``Author-email``
-* ``Maintainer``
-* ``Maintainer-email``
-* ``Keywords``
-* ``Classifier``
-* ``Project-URL``
+* ``Platform``
+* ``Supported-Platform``
+* ``Requires-Dist``
+* ``Requires-External``
+* ``Provides-Extra``
+* ``Provides-Dist``
+* ``Obsoletes-Dist``
 
 As it adds a new metadata field, this PEP updates the core metadata
 format to version 2.2.
@@ -116,15 +114,9 @@ format to version 2.2.
 Source distributions MUST use the latest version of the core metadata
 specification (which will be version 2.2 or later).
 
-The ``Requires-Python`` field for a project may vary by target platform,
-but is not allowed to be declared as ``Dynamic`` in the sdist metadata.
-To handle this situation, build backends MUST use environment markers on
-the ``Requires-Python`` field to allow that metadata to remain common
-across the sdist and all wheel archives, rather than generating platform
-dependent ``Requires-Python`` metadata as part of the wheel build
-process.  Build backends SHOULD also use this approach for other
-metadata fields that may vary by target platform (e.g. dependency
-declarations).
+Build backends SHOULD encourage projects to avoid using ``Dynamic``,
+preferring to use environment markers on static values to adapt to
+details of the install location.
 
 Backwards Compatibility
 =======================
@@ -173,38 +165,31 @@ Rejected Ideas
    does not seem to be enough benefit to this approach to make it worth
    using instead of the proposed mechanism.
 
+3. Allow ``Requires-Python`` to be ``Dynamic``, as it cannot include environment
+   markers to tailor the requirement to the target environment.
+
+   Currently, no projects on PyPI have a ``Requires-Python`` value that varies
+   between different wheels for the same version, so there is no practical
+   need for this flexibility at present. If a genuine use case is identified
+   later, the specification can be changed to allow ``Rquires-Python`` to be
+   dynamic at that time.
+
+4. Allow ``Dynamic`` to be used in wheels and/or installed distributions.
+
+   There is no obvious value to allowing this, and it seems like it is simply
+   adding complexity for no real reason. Allowing this could be done in a
+   follow-up proposal if there turned out to be sufficient benefit.
+
+5. Allow a field to be marked as ``Dynamic``, but *also* have a value in the
+   sdist metadata.
+
+   There appears to be no use case for allowing this. If a use case is
+   identified in the future, the specification can be updated at that time.
+
 Open Issues
 ===========
 
-1. Should we allow ``Dynamic`` to be used in wheels and/or installed
-   distributions?
-
-   ``Dynamic`` has no obvious meaning in either of these situations, and
-   the PEP therefore disallows it. However, backends may find it useful
-   to simply copy the field across, and it may have some usefulness in
-   recording "other wheels built from the source this came from may have
-   different values". However, the value seems marginal, and the added
-   complexity involved in explaining the feature does not seem worth it.
-
-   Allowing this could be done in a follow-up proposal if there turned
-   out to be sufficient benefit.
-
-2. If a field is marked as ``Dynamic``, but has a value in the sdist
-   metadata, how should that be interpreted?
-
-   The simplest answer is to just not allow dynamic fields to have a
-   value in the sdist at all. For now, this is what the PEP proposes.
-   But is there benefit in having a value which tools can take as a
-   "hint" for what the value in the wheel will be?
-
-3. Should this PEP change the canonical source for the sdist
-   specification to the `PyPA Specifications`_ document?
-
-   It would be beneficial to collect all of the details of the sdist
-   format in one place. However, distribution formats are not currently
-   collected there, and making the move would extend the impact of this
-   PEP significantly.
-
+None
 
 References
 ==========