A bit too strict pyproject.toml validation for uv 0.1.16 #2302
Description
Problem description
The uv 0.1.16 started to do quite stronger validation of pyproject.toml (IMHO a bit too strong) and I think it's not good as it excludes projects that are using things on a bleeding edge. This covers for example extensions of pyproject.toml that are not yet accepted, but already supported by popular tools. This is especially important if the features in pyproject.toml are related to build backend not frontend, because it's quite safe to assume by projects that they can add the features if they know the backend they are using supports it.
What happened
When we try to install Airflow in editable mode inside of our image with uv 0.1.16 we get this error (all works fine with uv 0.1.15) - it's the same error with pip uninstall and pip install:
#58 0.485 + xargs uv pip uninstall --python /usr/local/bin/python
#58 0.847 error: Querying Python at `/usr/local/bin/python3` failed with status exit status: 1 with exit status: 1
#58 0.847 --- stdout:
#58 0.847
#58 0.847 --- stderr:
#58 0.847 Traceback (most recent call last):
#58 0.847 File "<string>", line 404, in <module>
#58 0.847 File "<string>", line 380, in get_scheme
#58 0.847 File "<string>", line 330, in get_distutils_scheme
#58 0.847 File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line 627, in parse_config_files
#58 0.847 pyprojecttoml.apply_configuration(self, filename, ignore_option_errors)
#58 0.847 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 67, in apply_configuration
#58 0.847 config = read_configuration(filepath, True, ignore_option_errors, dist)
#58 0.847 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 128, in read_configuration
#58 0.847 validate(subset, filepath)
#58 0.847 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 56, in validate
#58 0.847 raise ValueError(f"{error}\n{summary}") from None
#58 0.847 ValueError: invalid pyproject.toml config: `project`.
#58 0.847 configuration error: `project` must not contain {'license-files'} properties
#58 0.847 ---
#58 0.853 + true
#58 0.853 + set +x
#58 0.853
#58 0.853 Installing all packages in eager upgrade mode. Installation method: .
#58 0.853
#58 0.854 + uv pip install --python /usr/local/bin/python --upgrade --resolution highest --editable '.[devel-ci]'
#58 1.162 error: Querying Python at `/usr/local/bin/python` failed with status exit status: 1 with exit status: 1
#58 1.162 --- stdout:
#58 1.162
#58 1.162 --- stderr:
#58 1.162 Traceback (most recent call last):
#58 1.162 File "<string>", line 404, in <module>
#58 1.162 File "<string>", line 380, in get_scheme
#58 1.162 File "<string>", line 330, in get_distutils_scheme
#58 1.162 File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line 627, in parse_config_files
#58 1.162 pyprojecttoml.apply_configuration(self, filename, ignore_option_errors)
#58 1.162 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 67, in apply_configuration
#58 1.162 config = read_configuration(filepath, True, ignore_option_errors, dist)
#58 1.162 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 128, in read_configuration
#58 1.162 validate(subset, filepath)
#58 1.162 File "/usr/local/lib/python3.8/site-packages/setuptools/config/pyprojecttoml.py", line 56, in validate
#58 1.162 raise ValueError(f"{error}\n{summary}") from None
#58 1.162 ValueError: invalid pyproject.toml config: `project`.
#58 1.162 configuration error: `project` must not contain {'license-files'} properties
Example failure in CI here: https://github.com/apache/airflow/actions/runs/8204894763/job/22440571526?pr=37995#step:6:1817
Context
We have an example of that in Apache Airflow. We are currently using license-files keys and .glob pattern in it coming from (still Draft) https://peps.python.org/pep-0639/ - and the license-files keys is nicely supported by hatchling 1.21.1 which we use as Apache Airflow build backend. This allows us to easily add multiple licences to our sdist/wheel metadata - both Apache Licence 2.0 and 3rd-partylicences of projects that we partially vendored-in. This is a legal requirement for us to add the licences when we redistribute the software and being able to do it using dedicated mechanism for that (even if it is not yet fully accepted) is pretty useful.
Here is an extract (important things only) from our pyproject.toml:
[build-system]
requires = [
...
"hatchling==1.21.1",
...
]
build-backend = "hatchling.build"
[project]
....
license-files.globs = ["LICENSE", "3rd-party-licenses/*.txt"]I think there are other projects that are using some upcoming features - even knowing that they might get rejected or changed, so I think better approach is to soften the validation - at least to allow some new unknown keys to appear there - maybe raise a warning and allow to silence them with a flag for those who are aware of this limitation and use uv for their CI/development tooling at least.