Given that this causes significant churn without a very clear benefit for users, we decided to wait with this change until the ecosystem is further along.

However, typing_extensions has not reverted this change.

PEP 639 explicitly recommends removing the license classifier. Ruff should lead by example in adopting PEP 639 and encourage tools such as pip-license to follow suit.

Given its wide adoption, Ruff, like typing_extensions, bears a responsibility to help advance the Python ecosystem. @MichaReiser @AlexWaygood

@AlexWaygood I understand the typing_extensions issues are caused by pip-licenses missing support for PEP 639 (raimon49/pip-licenses#225 and raimon49/pip-licenses#213), aren't they?

But then the Test Plan in #19624 (comment) seems to suggest that uv build --sdist might not add the LICENSE file to the package. @ntBre Could you shed some light on the actual problem with #19499?

But then the Test Plan in #19624 (comment) seems to suggest that uv build --sdist might not add the LICENSE file to the package. @ntBre Could you shed some light on the actual problem with #19499?

This is the reason why we reverted the entire change and it requires a fix to maturin first.

Are you certain this is an issue with maturin? In theory, maturin ≥ 1.9 is supposed to support PEP 639:
https://www.maturin.rs/changelog.html

As far as I can understand, this is an issue with pip-licenses which is unable to find the licensing information in package metadata. Are you really implying the licensing information is missing from package metadata?

According to https://github.com/raimon49/pip-licenses/blob/master/README.md#option-from:

this tool finds the license from Trove Classifiers or package Metadata.

Change #19499 does two things:

1. Removing the classifier, which means pip-licenses will be unable to find licensing information in classifiers and should fall back to package metatdata.
2. Modifying licensing declaration in pyproject.toml which modifies package metadata. I must admit I don't know which exact changes are applied by maturin, but see below the changes applied by setuptools.

Using setuptools, a pyproject.toml file looking like this:

license = {text = "GPL-3.0-or-later"}
classifiers = [
    "License :: OSI Approved :: GNU General Public License v3 (GPLv3)",
]

yields a PKG-INFO like this one, with the LICENSE file found without explicit declaration:

License: GPL-3.0-or-later
Classifier: License :: OSI Approved :: GNU General Public License v3 (GPLv3)
License-File: LICENSE

while such a pyproject.toml file:

license = "GPL-3.0-or-later"

yields a PKG-INFO like this one:

License-Expression: GPL-3.0-or-later
License-File: LICENSE

I believe pip-licences does not support the switch from License to License-Expression in package metadata, which is caused by the switch from license = {text = "..."} to license = "..." in pyproject.toml. However, this could be mitigated by keeping the Trove classifier for compatibility. How does this sound?

A maturin maintainer identified it as a bug https://github.com/PyO3/maturin/compare/konsti/add-license-files-to-sdist

Once the maturin bug is fixed, hopefully in release 1.9.3, perhaps #19499 can be reconsidered as #19661.

It turns out pip-licences is not much maintained and has been forked into pip-licenses-cli which does support PEP 639. Not sure it's worth taking it into account.

Maturin 1.9.3 with the fix for source dist license file inclusions is out