An interesting issue popped up on uv’s issue tracker. cryptacular 1.6.2 fails to build because the build backend uses they keyword “settings ” instead of “config_settings” for the prepare metadata for build wheel call. This works in pip because pyproject-hooks positionally passes in these arguments.
My questions are:
Should pyproject-hooks attempt to enforce the names by calling them via keyword arguments?
Or, should the spec be updated that all calls should be positional?
Or, should this be left as an implementation detail between frontend and backends?
2 Likes
pradyunsg
May 10, 2024, 7:14pm
2
If we had to enforce something, I’d prefer we’d enforce named calls.
TBH though, I’d consider this an issue with the backend and not the frontend – the signature is well specified and the relevant project is not implementing that signature.
5 Likes
I completely agree, and that reminded me to file an issue: `prepare_metadata_for_build_wheel` and others incorrectly use name "settings" not "config_settings" · Issue #42 · dholth/enscons · GitHub
The discussion I wanted to bring up was that if it’s not being enforced by pyproject-hooks it’s very easy for backends to slip up here.
1 Like
I’ve changed uv to pass arguments positionally for now, and also submitted a PR to enscons to update the signature: Rename `settings` to `config_settings` in PEP 517 hooks by charliermarsh · Pull Request #43 · dholth/enscons · GitHub . My personal opinion is that the build backend is not adherent to the spec, and callers should be able to pass positional or named arguments as long as they comply with the specified signature.
6 Likes
dholth
July 20, 2024, 7:11pm
5
That part may have been written before the spec. Thanks for the PR.
2 Likes