Hi there
Charalampos Stratakis via python-devel venit, vidit, dixit 2026-03-21 02:11:36:
> More and more packages move to pyproject macros that make use of upstream
> metadata. Upstream Python projects frequently pin or constrain dependency
> versions (e.g. numpy<2.0, attrs==25.3). When Fedora ships a different
> version, packagers currently resort to sed/patch in %prep to modify
> pyproject.toml, requirements.txt, setup.cfg etc. This is quite fragile and
> honestly a pain point every time as it breaks on upstream reformatting,
> varies across build systems and pollutes the spec. And I'm not the biggest
> fan of deciphering regexes.
It's good to have a uniform solution.
> The reasoning for only one override per macro call is that each override
> should be verified and possibly commented on why it's needed, instead of
> blindly removing dependencies. Also having one per line will keep the spec
> readable. More than one argument in the macro call will make it error out.
Yes!
> *Available actions*
>
> - drop_upper: remove upper-bound constraints (<, <=, ==, ~=)
> - drop_lower: remove lower-bound constraints (>, >=, ==, ~=)
> - drop_constraints: remove all version constraints
Maybe drop_any? Because "constraints" applies to all macros and is not
specific.
> - set_upper: replace the upper bound with < VALUE
> - set_lower: replace the lower bound with >= VALUE
I'm surprised by those two - both by the asummetry as well as the
choice.
Typically, the upper bound is the last known good version, so I'd expect
"<=" instead of "<". In particular, you may not even know what the next
version beyond the good one will be so that you don't know the value
"next(good)".
For lower, it's not as clear cut. Here, you typically know the lowest
version which works (">=") as well as the one before which breaks things
(">") so that packagers could live with both ways to specify things. I'd
do it symmetrically.
> - ignore: remove the dependency entirely
>
> Note: == and ~= act as both upper and lower bounds, so either drop_upper or
> drop_lower will remove them. Exclusions (!=) are always preserved.
If drop_{upper,lower} both include "=" then applying them to an "=="
should transform the "==" into ">=" resp. "<=", shouldn't it? That would
be both logical as well as practical - you can always
"drop_contstraints" if you really mean it.
Exclusions should not be preserved with "drop_any/constraints", should
they?
Logically speaking, "!= v" is "( < v OR > v )" so one could say
drop_upper" should turn this into "> v" and "drop" should remove it.
Finally, the spec says that "~= V.N" is rougly equivalent to
">= V.N, == V.*" which is the obvious lower bound plus an effective
upper bound, so that I would expect drop_{lower,upper} to tranform "~="
accordingly.
... just following the principle of least surprise :)
Cheers
Michael
--
_______________________________________________
python-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
