On 03/02/18 18:24, Jason L Tibbitts III wrote:
"MH" == Miro Hrončok <mhron...@redhat.com> writes:
MH> I expect it to be called for both 2 and 3 unconditionally. Hiding
MH> the condition in the maro makes things too magical for me.
I don't think that stance holds up well as we increasingly hide things
in macros and will continue to hide even more. (I'd like to see even
more hidden with macros, up to having whole classes of specfiles
completely generated by macros.)
Sure, let's hide things in macros. But I see this discussion as one
level below that: it's the thing that we'll want to hide in those macros.
As I said in my proposal: Let's (later) add "%py_build_all" that
conditionally calls py3_build and py3_build. Discussing that is
intentionally left as the next step, though.
IOW, let's design the explicit version, and only hide *that* in macros,
so advanced users can go one level down and still find a well-designed
system underneath. An unstructured magic macro is a pain to debug.
And I can certainly understand the git branch thing, but if we
universally adopt and integrate %{with python3} as the conditional and
you're manually passing --without python3 then why would you really want
%py3_build to be executed unconditionally? The principle of least
surprise would suggest that it isn't executed.
I *really* don't want to change the behavior of %py3_build (which we
currently define and promote as best practice), or of %with_python3
(which many packages currently define).
Generating whole classes of specfiles completely by macros is a worthy
goal, but it needs to be opt-in. We have hundreds of packages that are
either lovingly hand-crafted or horribly cargo-culted, and we don't want
to break them more than necessary.
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
