On 27. 03. 24 23:15, Maxwell G 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.
Yeah, I think -p (for *p*yproject) is good flag name choice.
Or even for [*p*roject] table. It is double good.
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.
I am not particularly keen on this.
This means that once the backend starts supporting it, all the spec files using
-p need to drop it. And if the backend only supports it in rawhide, the spec
files need to diverge and/or %if-guard the flag.
If the backend followed PEP 621 before adding the hook and now it added the
hook, it is unlikely the PEP 621 support was dropped.
OTHO if the backed was changed (e.g. meson -> poetry), this *could* happen. So
I am not entirely opposed for this guard.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok