-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
PEP 639: Further update per discussion, w/flat license key, etc. #2705
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
Conversation
3140037 to
75d3eda
Compare
75d3eda to
e59ccc9
Compare
JelleZijlstra
left a comment
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
glossaryand 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-expressionkey for the license expression in the[project]table of thepyproject.tomlsource metadata, the PEP now specifies using the top-level string value of thelicensekey for this purpose, which PEP 621 (PEP-621) reserved it for, and updates thelicense-expressionandlicensekey specs, and the examples, rejected ideas and other sections accordingly.licensekey to the newLicense-Expressionfield 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_filesdirectory was renamed tolicensesat the request of @brettcannon and to simplify things a touchlicense.filekey was a bit confused by a (apparently quite common) misunderstanding about how the specified file is used (to inject its text directly under theLicensefield 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: