Skip to content

Update license metadata in pyproject.toml according to PEP 639 #12807

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

facutuesca
Copy link
Contributor

@facutuesca facutuesca commented Apr 25, 2025

setuptools now warns when building a project that uses license classifiers:

DEBUG /github/home/.cache/uv/builds-v0/.tmpjaMf3z/lib/python3.13/site-packages/setuptools/dist.py:759: SetuptoolsDeprecationWarning: License classifiers are deprecated.
DEBUG !!
DEBUG 
DEBUG         ********************************************************************************
DEBUG         Please consider removing the following classifiers in favor of a SPDX license expression:
DEBUG 
DEBUG         License :: OSI Approved :: MIT License
DEBUG 
DEBUG         See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
DEBUG         ********************************************************************************
DEBUG 
DEBUG !!

This is due to PEP 639, which changes the way the licenses (and their files) are specified in the project metadata (see also the packaging guide here). This is supported since version 77.0.3 of setuptools.

This PR changes the metadata accordingly, and bumps the minimum version of setuptools to ensure it's supported.

cc @woodruffw @alex

@alex
Copy link
Member

alex commented Apr 25, 2025

I think we want to leave the setuptools version alone (for 3.7 support) and just update the metadata. People on old setuptools will get marginally wrong stuff, and I guess that's ok.

@facutuesca facutuesca force-pushed the ft/license-metadata branch from 429cd7c to eb99821 Compare April 25, 2025 21:35
@facutuesca
Copy link
Contributor Author

facutuesca commented Apr 25, 2025

ah but I think that it will cause their builds to outright fail:

If you get a build error that license should be a dict/table, your build backend doesn’t yet support the new format. See the above section for more context. The now deprecated format is described in PEP 621.

(from https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license)

@facutuesca facutuesca marked this pull request as draft April 25, 2025 21:40
@alex
Copy link
Member

alex commented Apr 25, 2025

Actually, why is setuptools even processing this? We use maturin for builidng the package?

@facutuesca
Copy link
Contributor Author

Actually, why is setuptools even processing this? We use maturin for builidng the package?

it seems to originate from this uv pip install call: https://github.com/pyca/cryptography/actions/runs/14663972603/job/41154408745#step:10:76

@facutuesca
Copy link
Contributor Author

🤦 the warning is not coming from cryptography, but rather while building cffi: https://github.com/pyca/cryptography/actions/runs/14663972603/job/41154408745#step:10:928

cffi is the package that has that License :: OSI Approved :: MIT License classifier

@alex
Copy link
Member

alex commented Apr 25, 2025

heh. well, probably good to do this cleanup either way, since maturin appears to handle it properly in all versions.

@facutuesca facutuesca marked this pull request as ready for review April 25, 2025 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants