uv
uv copied to clipboard
Skip `get_requires_for_build_wheel` for build backends that always return `[]`
This is a probably-unsafe optimization we could perform, but e.g., poetry-core always returns [] (https://github.com/python-poetry/poetry-core/blob/21b00338544f52df7c3ba320f5f242a2fc815b65/src/poetry/core/masonry/api.py#L20C1-L20C1). So if we're using a version of poetry-core that we know always returns [], we could skip that step entirely.
I looked at some of the others and:
flitdoes need it (https://github.com/pypa/flit/blob/b2e3491a2f64dfac6649dce5ee20aecea9a01858/flit_core/flit_core/buildapi.py#L21).hatchlingdoes need it (https://github.com/pypa/hatch/blob/7b1ef02af717101d006d9801bca6f246ecb46892/backend/src/hatchling/build.py#L37)setuptoolsdoesn't need it (I think)
Not sure what else is popular.
@konstin - I feel like this would be a pretty sketchy but maybe interesting to you.
(Not sure if we should do this.)
maturin also has it hardcoded: https://github.com/PyO3/maturin/blob/1369b2779a05645fe5e96fec98ef2cdffb6400eb/maturin/init.py#L122-L127
To list our options:
- We could maintain a list of backends and versions with a static return value. We put it on a separate repo into github releases, download and cache it and only update it when we encounter a too new version.
- We could parse the file of the backend module (and hope they perform no import shenanigans). We know how to do this really fast from ruff, but it would pull in at least ruff's parser.
- We ask backend authors if they are willing to expose additional metadata that allows to skip that hook
- The call overhead becomes irrelevant due to https://github.com/astral-sh/puffin/issues/846
Hoping the last item is fine.
Although the first item would be my second choice.
setuptools doesn't need it (I think)
Actually setuptools does need get_requires_for_build_wheel. By default it returns wheel, but it also returns setup_requires entries.
Related: https://github.com/astral-sh/uv/issues/1582
@sbidoul -- Thank you!
I think this isn't gonna work.