Support for PEP 639 license specifiers in pyproject.toml

[luziferius]

Pip-tools seems incompatible with PEP 639-compatible license specifications in pyproject.toml. Trying to implement that causes pip-tools to fail when parsing the file.

With a pip-tools compatible pyproject.toml file, new setuptools versions say this:

/tmp/build-env-jaz9xswi/lib/python3.13/site-packages/setuptools/config/_apply_pyprojecttoml.py:82: SetuptoolsDeprecationWarning: `project.license` as a TOML table is deprecated
!!

        ********************************************************************************
        Please use a simple string containing a SPDX expression for `project.license`. You can also use `project.license-files`. (Both options available on setuptools>=77.0.0).

        By 2026-Feb-18, you need to update your project and remove deprecated calls
        or your builds will no longer be supported.

        See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
        ********************************************************************************

!!

So there are about 7 months left, until setuptools becomes incompatible with pip-tools.

Following the link given by setuptools gives a suggested fix:

[project]
license = "GPL-3.0-or-later"
# or
license = "MIT AND (Apache-2.0 OR BSD-2-Clause)"

Trying to apply this by replacing the license table in my project's pyproject.toml file results in the reported failure to run.

Environment Versions

1. Linux
2. Python version: Python 3.13.3
3. pip version: 25.1.1
4. pip-tools version: 7.4.1

Steps to replicate

1. Have a PEP 639-compliant license specifier in pyproject.toml
2. Run pip-compile

Expected result

Compiled requirements generated

Actual result

pip-tools compile outputs:

Backend subprocess exited when trying to invoke get_requires_for_build_wheel
Failed to parse /home/thomas/Projekte/MTGProxyPrinter/pyproject.toml

[webknjaz]

That's output from setuptools concerning whatever project you're building. You'll get the same when running any other build frontend, be it pip install or uv install, or python -Im build.

Build backends (like setuptools) are what's responsible for producing that core packaging metadata. If there's a project in your tree that needs to update their packaging config, you should ask them.

This bit of metadata isn't something that pip-tools even looks into.

[webknjaz]

Oh, I see. You must be adding a partial PEP 621 config with just the metadata key in the [project] table. setuptools is alergic to that. Usually, when you start using that, you must at least fill out the mandatory fields (in most cases of pure-python projects, you can migrate all of your metadata configuration in there instead of setup.cfg / setup.py). Still, this has nothing to do with pip-tools, really.

[luziferius]

Ah yeah. Sorry. This is actually invalid, but not for the reason you state…

The pyproject.toml that caused this issue

Replacing
license = {text = "GNU GPLv3+, see LICENSE.md or https://www.gnu.org/licenses/gpl-3.0.html for details"}
with
license = "GPL-3.0-or-later"
made python -m piptools compile pyproject.toml error out as stated in the initial issue.

The actual root cause for the issue is setuptools refusing to parse pyproject.toml after applying one of the suggested changes to it. As a side-effect, this change also elevates the warning about the deprecated license classifier that is present in the file from warning to error. And that error made piptools quit with "failed to parse pyproject.toml".

[webknjaz]

@luziferius setuptools requires you to drop the trove specifier too, when migrating to PEP 639-style metadata.
Although, the spec does not mandate that, it does mention that the build backends are allowed to error out: https://peps.python.org/pep-0639/#deprecate-license-classifiers. This isn't very graceful in terms of backwards compat.

We can't control the behavior of build backends. And if you want some level of reproducibility, you could make a constraint file with --build-deps-for=wheel --only-build-deps and use it via an env var like PIP_CONSTRAINT=build-deps.txt.

That said, do you think there's anything that pip-tools could do?

[luziferius]

Yeah, noticed that the hard way. xD

The way pip-tools converted the error raised by the backend into a human-readable error message "Failed to parse /home/thomas/Projekte/MTGProxyPrinter/pyproject.toml" led me to think this was some sort of schema validation code on pip-tools' side failing to recognize the new style license classifier and then fully rejecting the file as invalid.

That said, do you think there's anything that pip-tools could do?

One thing you could potentially do is not silencing the root cause error. So when pip-compile fails because a backend raises an exception, it could output something like "Failed to parse {file}.\n Received backend error message: {error_msg}" to pass the error info along, if possible. So for imported modules, catch and print exceptions, for subprocesses, check the return value and print the stderr channel, if non-empty.