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 -- _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
