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

Reply via email to