Fix the build for modern setuptools

[vanschelven]

No description provided.

[vanschelven]

I ran into this when doing a similar fix on one my own projects and then grepping in my "under active development" directory for other packages running into the same.

My super-non-scientific process was: read setuptools' error messages and do as they say. This also means: I didn't bother to check which particular version of setuptools broke the build.

[vanschelven]

I just noticed on another one of my projects that this "fix" breaks against Python 3.8

Thus, we'll need to wait until gunicorn drops Python 3.8 support #3343

However, the present PR will need to make it in before By 2026-Feb-18, because according to the message:

By 2026-Feb-18, you need to update your project and remove deprecated calls

[pajod]

until gunicorn drops Python 3.8 support

Worse. Its not just a matter of disregarding 3.8 (EoL). Gunicorn is used in stable distributions. E.g. Debian 13 "trixie" - release date still TBA but approaching hard freeze on 2025-05-15 - for cPython 3.13 is at this time distributing setuptools 75.8, which is before 77.0.3. So Gunicorn simply cannot use fields that setuptools in their quest for minimizing portability has chosen to deprecate with impractical transition timeframe.

• [Docs] Need migration guide for license expression (PEP 639) about TOML-table-based project.license deprecation if v77 unavailable  pypa/setuptools#4903
• https://peps.python.org/pep-0621/#license (deprecated)
• https://peps.python.org/pep-0639/#add-license-file-field (superseded) => https://packaging.python.org/en/latest/specifications/pyproject-toml/#license

--

Possible strategies for the last release before 2026-02-18:

1. pin build-system.requires - those using modern setuptools can call python -m build and it will fetch a (possibly older than installed) suitable version, those with a policy for sticking to trusted libraries will either a) have do deal with patching just about every python package or b) are using older setuptools.
2. stop mentioning license and trust all setuptools versions to detect the LICENSE file and do the right thing.
   • this will still trigger a warning about using License :: OSI Approved :: MIT License but that is just about the non-SPDX classifier, which is not planned to be turned into a hard error
   • having License-File: LICENSE in the python project metadata is still clear enough

[vanschelven]

@pajod inasmuch as I have taken the time to understand what you're saying, I agree with your analysis of the situation, including its root cause 😢

Here's the proof of Trixie's setuptools version: (note that Trixie's EOL hasn't even been announced yet, but is likely to be at least in 2030).

My personal way forward would probably be the "do it damnit" solution of getting rid of the license info altogether (nr. 2) but I have no strong opinion on this.