iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 621: Clarify points brought up from public consultation (#1465)

This commit is contained in:
Brett Cannon 2020-06-25 12:08:57 -07:00 committed by GitHub
parent 8c42fb4697
commit cccbc3256c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
pep-0621.rst
View File

@ -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 ``[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 defined by this PEP. For tools wishing to store their own settings in
``pyproject.toml``, they may use the ``[tool]`` table as defined 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`` ``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 assume the content-type is ``text/markdown``. If the file path ends in
a case-insensitive ``.rst``, then tools MUST assume the content-type a case-insensitive ``.rst``, then tools MUST assume the content-type
is ``text/x-rst``. If a tool recognizes more extensions than this PEP, 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 they MAY infer the content-type for the user without specifying this
suffixes, tools MUST raise an error. 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 The ``readme`` field may also take a table. The ``file`` key has a
string value representing a relative path to a file containing the 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 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 the metadata does not specify the ``charset`` parameter, then it is
assumed to be UTF-8. Tools MAY support other encodings if they choose 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`_. transform to a content-type as supported by the `core metadata`_.
Otherwise tools MUST raise an error for unsupported content-types. 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 3. If both ``email`` and ``name`` are provided, the value goes in
``Author-email``, with the format ``{name} <{email}>``. ``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`` ``keywords``
'''''''''''' ''''''''''''
- Format: array of strings - Format: array of strings