On 27-03-2024 15:48, Karolina Surma wrote:
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?
I'd be in favor of option two in combination with option three. That is,
set a flag explicitly two enable the behavior described in option two,
fallback to pyproject.toml if hook is not available.
Doing it that way also means the current behavior remains unchanged for
package maintainers being unaware similar to the -l flag of
%pyproject_save_files.
I'm approaching this purely from a packager's point of view. I dislike
having the wheel built twice, once for the metadata and again for the
package itself.
The documentation could point to the build backends, where it makes
sense enabling -p, e.g. meson-python.
-- Sandro