Open mgorny opened 2 years ago
Thanks for reporting @mgorny.
It seems that @frostming was faster than me and implemented a workaround in pdm-pep517
😄 (thank you very much Frost!)
@frostming, if you prefer a different approach, I don't mind disabling the validation in setuptools, but we have to agree on a mechanism for the wrapper to communicate with setuptools[^1].
We also need to ensure that some validation is done somewhere (there are code paths in the setuptools implementation that rely on the existence of the validation).
[^1]: Checking the value of [build-system] build-backend
does not sound like a good solution for me: some lightweight wrappers might want the validation to happen while others want to completely take over...
To be honest, I don't think the workaround fully fixes the problem — it silences the test failure but some real package could still fail if it used C extensions in combination with incompatible pyproject.toml
keys.
I am more than happy to tackle this at setuptools level. I just would like us to agree on the approach.
PEP 517 acknowledges the existence of backend wrappers, which means that it is perfectly fine for the value of [build-system] build-backend
to be other than setuptools.build_meta
and setuptools still be the main "driver" behind the build[^1].
With that in mind:
(a) Lightweight wrappers should rely on the same validations that setuptools uses by default.
(b) Other wrappers might want to take over and disable the validations or the whole processing of pyproject.toml
.
I would like to agree on a approach to unequivocally identify the situation in (b)
, then we can make setuptools step aside.
[^1]: This is true not only for small in-tree wrappers, but also for other backends that extend setuptools via entry-points, e.g. pbr
.
setuptools version
61.3.0
Python version
Python 3.10.4
OS
Gentoo Linux
Additional environment information
Tested on top of pdm-pep517 git (pdm-project/pdm-pep517@04ed8589ad4400422ac9ca4c09b3ecb0df8edfab). pdm-pep517 bug report: https://github.com/pdm-project/pdm-pep517/issues/81
Description
pdm-pep517 happens to use setuptools internally to build projects with C extensions. However, these builds are now failing due to setuptools attempting to validate
pyproject.toml
according to its own rules, while it apparently uses an incompatible pdm-specific format. An example error is:Expected behavior
Not sure. Possibly skipping validation if
pyproject.toml
uses a different build system.How to Reproduce
Output
The tests initially fail due to empty
homepage
:After fixing it not to be empty, they fail due to pdm-specific keys, e.g.: