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: reviewer feedback (#1714)

This commit is contained in:
Brett Cannon 2020-11-13 13:17:42 -08:00 committed by GitHub
parent 855ab61a82
commit 19bac6162a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0621.rst
View File

@ -446,9 +446,8 @@ provided via tooling later on.
(i.e. ``dynamic`` is the only way to allow a tool to fill in (i.e. ``dynamic`` is the only way to allow a tool to fill in
metadata and the user must opt into the filling in). metadata and the user must opt into the filling in).
- Build back-ends MUST raise an error if the metadata specifies a - Build back-ends MUST raise an error if the metadata specifies a
field in ``dynamic`` but is still unspecified in the final artifact field in dynamic but the build back-end was unable to provide the
(i.e. the build back-end was unable to provide the data for a field data for it.
listed in ``dynamic``).
Example Example
------- -------
@ -519,12 +518,6 @@ statically define project metadata. Any security issues would stem
from how tools consume the metadata and choose to act upon it. from how tools consume the metadata and choose to act upon it.
How to Teach This
=================
[How to teach users, new and experienced, how to apply the PEP to their work.]
Reference Implementation Reference Implementation
======================== ========================
@ -669,12 +662,6 @@ things for build back-ends as they would have to make sure to traverse the full
table structure rather than a single level and raising errors as appropriate on table structure rather than a single level and raising errors as appropriate on
value types. value types.
Backfilling trove classifiers SHOULD occur instead of MAY happen
----------------------------------------------------------------
Originally this PEP said that tools SHOULD backfill appropriate trove classifiers.
This was changed to say it MAY occur to emphasize it was entirely optional for
build back-ends to implement.
Using structured TOML dictionaries to specify dependencies Using structured TOML dictionaries to specify dependencies
---------------------------------------------------------- ----------------------------------------------------------
The format for specifying the dependencies of a project was the most The format for specifying the dependencies of a project was the most
@ -688,8 +675,8 @@ The authors briefly considered supporting both formats, but decided
that it would lead to confusion as people would need to be familiar that it would lead to confusion as people would need to be familiar
with two formats instead of just one. with two formats instead of just one.
Require build backe-ends to update ``pyproject.toml`` when generating an sdist Require build back-ends to update ``pyproject.toml`` when generating an sdist
------------------------------------------------------------------------------ -----------------------------------------------------------------------------
When this PEP was written, sdists did not require having static, When this PEP was written, sdists did not require having static,
canonical metadata like this PEP does. The idea was then considered to canonical metadata like this PEP does. The idea was then considered to
use this PEP as a way to get such metadata into sdists. In the end, use this PEP as a way to get such metadata into sdists. In the end,