refactor: remove special case

Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>

Author: henryiii

peps/pep-0808.rst

@@ -16,8 +16,8 @@ Abstract
 
 This PEP relaxes the constraint on dynamic metadata listed in the ``[project]``
 section in ``pyproject.toml`` to allow the static portion of mixed metadata to
-be defined in the normal location if the field is a table, array or ``license``
-by having the dynamic fields extend the static ones.
+be defined in the normal location if the field is a table or array by having
+the dynamic fields extend the static ones.
 
 This allows users to opt into allowing a backend to extend metadata while still
 keeping the static portions of the metadata defined in the standard location in
@@ -92,9 +92,7 @@ Every list and every table with arbitrary keys will now be allowed to be
 specified both statically, in the ``[project]`` table, and in the
 ``project.dynamic`` list. If it is present in both places, the build backend
 can extend list items and add new keys, but not modify existing list items or
-strings. We are also including one special case; the ``license`` field when
-specified as a string is an SPDX expression, which has a similar concept of
-extension with ``AND``.
+strings.
 
 
 Use Cases
@@ -122,17 +120,13 @@ cases that have come up:
   and inject them (Poetry_ being the best known example).
 - Adding license files to the wheel based on what libraries are linked in (this
   is an active discussion in followup to :pep:`639`).
-- Similarly, adding licenses based on vendored code (the setuptools_ repo might be
-  able to use this.)
 - Adding SBom's when building - :pep:`770` had to remove the ``pyproject.toml``
   field specifically because you _want_ the build tool to add these, so the
   ``[project]`` table setting would be useless, you'd almost never be able to
   use it.
 
 All of these use cases have a similar feature: they are adding something
 dynamically to a fixed list (possibly a narrower pin for the dependency case).
-With the exception of the recently added ``license`` field, these are all lists
-or tables that need extending.
 
 You can implement these today, but it requires providing a completely separate
 configuration location for the non-extended portion, and static analysis tools
@@ -195,40 +189,10 @@ longer needs to create and document a new location for the standard
 example).
 
 
-Example: licenses
------------------
-
-As another example, a package could specify its license(s):
-
-.. code-block:: toml
-
-   [project]
-   license = "MIT"
-   license-files = ["LICENSE"]
-
-   dynamic = ["license", "license-files"]
-
-   [tool.my-build-backend]
-   license-search-sdist = ["vendor/*"]
-   linked-wheel-licenses = true
-
-
-Now a build-backend can search for licenses in the vendor folder, and add them
-automatically to the license expression and/or file list. If it supports this
-when creating the wheel, it can specify the necessary fields in the ``Dynamic``
-``METADATA`` (2.2+) field and then add the licenses that are linked in when
-creating the wheel. While you can do this today, you can't specify the
-project's own license statically when you do this; this PEP allows both.
-
 
 Future Updates
 --------------
 
-New fields added to the ``[project]`` table in future PEPs should include how
-to handle additive dynamic metadata if they need special handling. Currently,
-there is only one special case (``license``), so this is not expected to be
-common.
-
 Loosening this rule to allow purely additive metadata should address many of
 the use cases that have been seen in practice. If further changes are needed,
 this can be revisited in a future PEP; this PEP neither recommends or precludes
@@ -250,8 +214,6 @@ now be allowed to be present in both the ``[project]`` table and the
 backend is allowed to insert entries into the list or table, but not remove
 entries, reorder entries, or modify the entries. Tables of arrays allow adding
 a new table entry or extending an existing array according to the rules above.
-As a special case, the ``license`` field, when set to a string SPDX expression,
-can be extended logically, as well.
 
 The fields that are arrays or tables with arbitrary entries are:
 
@@ -266,8 +228,6 @@ The fields that are arrays or tables with arbitrary entries are:
   be changed or removed.
 * ``keywords``: Keywords can be added to the list.
 * ``license-files``: Files can be added to the list.
-* ``license`` (string, special case): The license expression can be extended.
-  An existing license cannot be logically excluded.
 * ``optional-dependencies``: A new extra or new items can be added to a
   existing extra.
 * ``urls``: New urls can be added. Existing ones cannot be changed or removed.
@@ -338,9 +298,7 @@ introductory packaging.
 
 The ``pyproject.toml`` `specification <pyprojectspec>`__ will be updated to
 include the behavior of fields when specified and also listed in the dynamic
-field. An example of such an update for the license field:
-
-* When also listed in ``dynamic``: Can be extended with ``AND``
+field.
 
 It should also be noted that specifying something in dynamic will require any
 tool that requires the full metadata to invoke the backend even if it is
@@ -359,13 +317,16 @@ the use cases seen, though, and an explicit, opt-in approach is better for
 static tooling.
 
 
-Include more string fields
---------------------------
+Include string fields
+---------------------
+
+Some string fields could also be extended. Most notably, the ``license`` field
+would benefit from being extendable, and due to the semantics of SPDX
+expressions, extension could be defined through ``AND``. This was not added to
+this PEP to keep it purely focused on arrays and tables.
 
-There are two more string fields, namely ``version`` and ``requires-python``
-(``name`` is not allowed to be specified dynamically). There did not seem to be
-a pressing practical need to allow these to be extended as with ``license``,
-and logical extensions are not as clear, so they are not included in this PEP.
+The other string fields, namely ``version`` and ``requires-python`` (``name``
+is not allowed to be specified dynamically), have less reason to be extended.
 Fixed key tables, like the deprecated ``license.text``/``license.file`` or
 ``readme.text``/``readme.file`` also have no clear benefit being partially
 dynamic.