On Wed Mar 27, 2024 at 15:48 +0100, Karolina Surma wrote:
Hello,
Hi Karolina,
Thank you for bring this to the mailing list.
recently, we were suggested an improvement for
%pyproject_buildrequires
-r/-x.
We could read the project's runtime dependencies (if they're not marked
as `dynamic`) from pyproject.toml [project] table directly, without
calling prepare_metadata_for_build_wheel or building the wheel to read
the dependency metadata from it.
Reading the metadata via prepare_metadata_for_build_wheel is already
quite fast, however implementing that hook is optional for the build
backends.
I'll note that all build backends packaged in Fedora (setuptools,
hatchling, flit-core, poetry-core, the pdm one, and scikit) other than
meson-python support this hook. Only 9 packages BuildRequire
python3-meson-python.
Maxwell has raised some valid concerns there:
- Other tools (build frontends, e.g. pip/build) call
prepare_metadata_for_build_wheel, our macros would diverge in
functionality compared to the rest of the landscape.
- pyproject.toml's [project] may not be the source of metadata that the
build backend uses. A project could switch to a build backend without
PEP 621 support (e.g. poetry-core) and forget to remove the [project] table.
- There can be potential differences between BuildRequires and Requires
generators when one generates dependencies based on the pyproject.toml
[project] table while the other on the packaged dist-info metadata.
- Using macros to build on older systems: e.g. RHEL 9's old setuptools
version silently ignores the pyproject.toml [project] table -
%pyproject_buildrequires could still pull the dependency information
from it, but the resulting package would be broken because it did not
include those in the packaged dist-info metadata.
I could not have said it better myself :D.
One way to mitigate would be to make the proposed behavior opt-in
only,
with the possibility to either build wheel with -w option (already
existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case
backend doesn't have prepare_metadata_for_build_wheel.
Yeah, I think -p (for *p*yproject) is good flag name choice.
However, this adds a layer of complexity for packagers and macros
maintainers.
The questions we'd love your input for:
- Should this behavior exist but not be the default (explicit flag
would be required to opt-in)?
I consider this the only reasonable solution other than not implementing
the feature at all.
- Can you think of a better alternative than the ones described
here?
I guess I will throw something out there, but I am not convinced it is a
great idea: what about making the `-p` flag fail if
`prepare_metadata_for_build_wheel` is available? In my opinion, this
should only be a last resort for backends that do not implement the hook.
—Maxwell