From 508379c76015ff7ccb39df609f673ee378011fa2 Mon Sep 17 00:00:00 2001 From: CAM Gerlach Date: Fri, 22 Jul 2022 14:32:35 -0500 Subject: [PATCH] PEP 639: Implement @JelleZijlstra 's suggested editorial fixes Co-authored-by: Jelle Zijlstra --- pep-0639.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/pep-0639.rst b/pep-0639.rst index c183c17ca0e..4e2e0c46c5d 100644 --- a/pep-0639.rst +++ b/pep-0639.rst @@ -140,9 +140,9 @@ including on `outdated and ambiguous PyPI classifiers `__, `the lack of clear, precise and standardized license metadata `__. The current license classifiers address some common cases, and could -theoretically be extended to include the full range of current SPDX +be extended to include the full range of current SPDX identifiers while deprecating the many ambiguous classifiers (including some -extremely popular and particularly problematic ones, such as +popular and problematic ones, such as ``License :: OSI Approved :: BSD License``). However, this both requires a substantial amount of effort to duplicate the SPDX license list and keep it in sync, and is effectively a hard break in backward compatibility, @@ -591,7 +591,7 @@ Add string value to ``license`` key A top-level string value is defined for the ``license`` key in the ``[project]`` table, -which specified to be a valid SPDX license expression, +which is specified to be a valid SPDX license expression, as :ref:`defined previously <639-license-expression-definition>`. Its value maps to the ``License-Expression`` field in the core metadata. @@ -696,7 +696,7 @@ Deprecate ``license`` key table subkeys ''''''''''''''''''''''''''''''''''''''' Table values for the ``license`` key in the ``[project]`` table, -including the ``text`` and ``file`` table subkeys, is now deprecated. +including the ``text`` and ``file`` table subkeys, are now deprecated. If the new ``license-files`` key is present, build tools MUST raise an error if the ``license`` key is defined and has a value other than a single top-level string. @@ -796,7 +796,7 @@ map to a single valid SPDX license identifier, allowing tools to infer the SPDX license identifier they correspond to, both for use when analyzing and auditing packages, and providing a semi-automated mechanism of filling the ``license`` key -or the the ``License-Expression`` field +or the ``License-Expression`` field following the :ref:`specification above <639-spec-converting-metadata>`. Some legacy license classifiers intend to specify a particular license, @@ -1254,7 +1254,7 @@ being dynamic and others static, and mapping to different core metadata fields. Furthermore, this leads to a conflict with marking the key as ``dynamic`` (assuming that is intended to specify the ``[project]`` table keys, as that PEP seems to imprecisely imply, -rather than core metadata fields), as either both would have +rather than core metadata fields), as either or both would have to be treated as ``dynamic``. Grouping both license expressions and license files under the same key forces an "all or nothing" approach, and creates ambiguity as to user intent. @@ -1316,7 +1316,7 @@ This was seen as clearer and more explicit for readers and writers, in line with the goals of this PEP. Additionally, while differences from existing tool formats (and core metadata -field names) has precedent in :pep:`621`, +field names) have precedent in :pep:`621`, using a key with an identical name as in most/all current tools to mean something different (and map to a different core metadata field), with distinct and incompatible syntax and semantics, does not, @@ -1331,7 +1331,7 @@ from the ``License-Expression`` field as this PEP currently allows without it as ``license`` as dynamic (which would not be possible, since they both map to the same top-level key). -However, community consensus was in favor instead using +However, community consensus favored using the top-level string value of the existing ``license`` key, as :pep:`reserved for this purpose by PEP 621 <621#license>`: @@ -1410,7 +1410,7 @@ as strictly speaking the ``license`` key is not (and cannot be) specified in ``pyproject.toml``, and satisfies a stricter interpretation of the letter of the previous :pep:`621` specification that this PEP revises. -However, this doesn't seen to be necessary, because it is simply using the +However, this doesn't seem to be necessary, because it is simply using the static, verbatim literal value of the ``license`` key, as specified strictly in this PEP. Therefore, any conforming tool can trivially, deterministically and unambiguously derive this using only the static data