-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP 639: Further update per discussion, w/flat license key, etc. #2705
PEP 639: Further update per discussion, w/flat license key, etc. #2705
Conversation
3140037
to
75d3eda
Compare
75d3eda
to
e59ccc9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good, but a few notes on wording
pep-0639.rst
Outdated
``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, | ||
forcing a huge proportion of package authors to immediately update to new | ||
classifiers (in most cases, with many possible choices that require closely | ||
examining the project's license) immediately when PyPI deprecates the old ones. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this is one sentence. It would be more readable if split up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done ✔️ , I made that change, caught a few other stray spaces and such and squashed it into the same commit with yours.
508379c
to
3965044
Compare
Going to go ahead and merge this soon unless anyone has any last feedback, and iterate further a final followup PR making the Terminology definitionlist into a glossary, linking the terms on first use in sections for clarity, adding additional ref targets, and taking advantage of the new Intersphinx support added in #2702 to link to the PyPA specs and glossary terms, making them simpler, more robust and more useful, as well as making it easier to both convert it to a PyPA spec, and review the same (avoiding some of the problems in pypa/packaging.python.org#1111). |
Merging now, I'll make any last changes (glossary, intersphinx, etc) in a followup. |
license
value instead of new key for expression & other updates
At long last, the next (and hopefully final) round of substantive PEP 639 (PEP-639) updates has arrived, based on the consensus of recent (and by now, not so recent) community discussions.
See the preview here
I was initially going to make the Terminology section into a Sphinx
glossary
and link the terms on first and prominient uses for clarity, but to speed things up and avoid scope creep I've deferred that to an immediate followup.In a final followup PR, I'll reduce the length of the PEP by a further ≈two thirds (on top of substantial earlier reductions and modest further trimming here) by moving all the appendices, the "Mapping License Classifiers to SPDX Identifiers" section (previously normative) and the full rejected ideas section (minus a concise summary of the most-discussed ones) to separate ancillary files linked from the appropriate places. Since I've already set the stage for that with the work in #2531, it should be a fairly straightforward and mostly mechanical change once this PR is editorially reviewed and merged.
Substantive content changes:
license-expression
key for the license expression in the[project]
table of thepyproject.toml
source metadata, the PEP now specifies using the top-level string value of thelicense
key for this purpose, which PEP 621 (PEP-621) reserved it for, and updates thelicense-expression
andlicense
key specs, and the examples, rejected ideas and other sections accordingly.license
key to the newLicense-Expression
field at build time, and that's not really advisable anyway, it drastically simplifies the normative Converting Legacy Metadata section to just a single normative statement, and updates/removes other mentions of it accordingly, and the (already rather unhelpful) examplelicense_files
directory was renamed tolicenses
at the request of @brettcannon and to simplify things a touchlicense.file
key was a bit confused by a (apparently quite common) misunderstanding about how the specified file is used (to inject its text directly under theLicense
field in core metadata, rather than included in distribution archives or its path specified in metadata) due to it being rather underspecified in PEP 621, which this revision corrects.Significant non-normative/editorial changes: