Hello,
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. When the hook is not available, we need to build the wheel,
which can be potentially very slow and resource-hungry (imagine building
the entire scipy project).
Metadata in pyproject.toml is standardized (PEP 621), however there is
no way of telling ahead of time if the build backend already supports
that standard.
See the details and discussion in bugzilla:
https://bugzilla.redhat.com/2261939
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.
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. However, this
adds a layer of complexity for packagers and macros maintainers.
The questions we'd love your input for:
- Should %pyproject_buildrequires try to read dependencies from
pyproject.toml first and fall back to calling hooks only if that fails?
- Should %pyproject_buildrequires call the hook and try to fall
back to reading dependencies from pyproject.toml when the hook is not
availbale?
- Should this behavior exist but not be the default (explicit flag
would be required to opt-in)?
- Can you think of a better alternative than the ones described here?
Cheers,
Karolina
--
_______________________________________________
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
