From cccbc3256c57d796448b1cfb587f7a157c40afe0 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Thu, 25 Jun 2020 12:08:57 -0700 Subject: [PATCH] PEP 621: Clarify points brought up from public consultation (#1465) --- pep-0621.rst | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/pep-0621.rst b/pep-0621.rst index 34a8a95d2..6890863a9 100644 --- a/pep-0621.rst +++ b/pep-0621.rst @@ -93,7 +93,8 @@ Tools MUST specify fields defined by this PEP in a table named ``[project]``. No tools may add fields to this table which are not defined by this PEP. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in -:pep:`518`. +:pep:`518`. The lack of a ``[project]`` table implicitly means the +build tool will dynamically provide all fields. ``name`` '''''''' @@ -172,8 +173,9 @@ file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, -they MAY infer the content-type for the user. For all unrecognized -suffixes, tools MUST raise an error. +they MAY infer the content-type for the user without specifying this +field as ``dynamic``. For all unrecognized suffixes when a +content-type is not provided, tools MUST raise an error. The ``readme`` field may also take a table. The ``file`` key has a string value representing a relative path to a file containing the @@ -186,7 +188,7 @@ specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose -to. Tools MAY support alternative content-types which they can +to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the `core metadata`_. Otherwise tools MUST raise an error for unsupported content-types. @@ -270,6 +272,14 @@ Using the data to fill in `core metadata`_ is as follows: 3. If both ``email`` and ``name`` are provided, the value goes in ``Author-email``, with the format ``{name} <{email}>``. +This use of the field is a slight deviation as the core metadata also +supports a ``Maintainer`` field which goes unused by this PEP. The +authors of this PEP felt this field was ambiguous and never clearly +defined. Other ecosystems have selected "author" as the term to use. +As such, it was decided it would be better to standardize on +``Author`` in the core metadata as the place to list people +maintaining a project. + ``keywords`` '''''''''''' - Format: array of strings