Implement PEP 639

[befeleme]

What's the problem this feature will solve? Standardized licensing metadata will in time unify the currently largely chaotic landscape.

Describe the solution you'd like See: https://peps.python.org/pep-0639 PEP 639 has been provisionally accepted with one of the conditions being implementation in PyPI.

[ewdurbin]

PyPI uses https://github.com/pypa/packaging to parse and validate metadata, so it will need an update to support the new metadata version, keys, and deprecations.

I've opened draft PRs for that and the packaging docs at:

• https://github.com/pypa/packaging/pull/828
• https://github.com/pypa/packaging.python.org/pull/1595

Once those PRs (or something that supersedes them) are merged, implementation in PyPI can begin.

[ewdurbin]

Draft PR is now up at https://github.com/pypi/warehouse/pull/16949 awaiting merge/release of https://github.com/pypa/packaging/pull/828.

[ewdurbin]

#16949 is now ready for review with the release of packaging 24.2

[ewdurbin]

PEP 639 implementation is live and online for PyPI now. We'll keep an eye out for issues filed if folks run into any issues as adoption takes off.

[di]

Reopening this because part of implementing PEP 639 is also deprecating the Licence metadata field and the various License :: trove classifiers. We should define a deprecation period, during which we warn users, and a suitable threshold for dropping support for these fields.

[ewdurbin]

By my read of 639, PyPI's responsibility is to not add any new license classifiers...

New license classifiers MUST NOT be added to PyPI; users needing them SHOULD use the License-Expression field instead. License classifiers may be removed from a new version of the specification in a future PEP.

I think deprecating them in the way proposed in https://github.com/pypa/trove-classifiers/pull/199 is left to a future pep.

[ewdurbin]

I'm also pretty certain we are already meeting the spec for the License field:

For all newly-uploaded distribution archives that include a License-Expression field, the Python Package Index (PyPI) MUST reject any that specify both License and License-Expression fields.

The License field may be removed from a new version of the specification in a future PEP.

https://github.com/pypi/warehouse/blob/9a270a2d01cba250795daf1e05133fbbafeeb7b0/warehouse/forklift/metadata.py#L238-L249

[ewdurbin]

I don't think there is further work to be done here without additional PEPs to remove license classifiers or remove the license field.

[di]

Reading https://peps.python.org/pep-0639/#backwards-compatibility more closely, I agree:

The legacy deprecated Core Metadata License field, license key table subkeys (text and file) in the pyproject.toml [project] table and license classifiers retain backwards compatibility. A removal is left to a future PEP and a new version of the Core Metadata specification.