Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

----- Original Message -----
> On 27 January 2015 at 21:26, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> > Hey all,
> > I just wanted to ask for some thoughts on a "problem" (or rather a
> > "hardship") that is starting to show with the Python 3 transition in
> > Fedora.
> > I've been contacted by two maintainers of "applications" in Fedora for
> > advice and have been thinking for some time how to solve this:
> >
> > Note: by "applications" I mean packages that provide end-user benefit and
> > don't need to be packaged for both Python interpreters. They just use some
> > Python (preferably the default one) to deliver functionality to user.
> > Let's take copr-cli as an example - this is a thin CLI wrapper around
> > python-copr.
> >
> > Current state:
> > - Up until F21, maintainers were encouraged to build applications with
> > Python 2, but weren't discouraged from building with Python 3.
> > - From F22 on, packagers will be encouraged to build with Python 3 rather
> > than Python 2.
> > - Lots of packagers want to keep the same specfile for EPEL and Fedora.
> > - Fedora guidelines mandate explicit usage of %__python2 and %__python3
> > (and all the sitelib/sitearch macros).
> >
> > The Problem:
> > If packagers want to build against Python 3 in Fedora and Python in EPEL
> > *and* keep the same specfile, they have to invent some ugly hacks, since
> > Fedora's guidelines require explicit usage of versioned Python macros.
> > This affects Requires and BuildRequires and %prep, %build, %install,
> > %check sections. People who want to do this either redefine %__python in
> > Fedora to point to Python 3 or something like that - I'm afraid that we
> > could end up with a huge pile of crazy macro redefinitions in tons of
> > packages and I want to avoid that.
> >
> > Proposed Solution:
> > After thinking a few days about this, here's what I propose:
> > - Every specfile will have a minimal header with macro definitions that
> > will look like this:
> >
> > %if 0%{?fedora}
> > %global default_python python3
> > %else
> > %global default_python python
> > %endif
> 
> I'm wary of this proposed solution mostly due to the fact that in the
> middle of last year, the Beaker team had to go through and completely
> redesign the way the automatic kickstart generation worked, because
> the templates were full of checks that assumed "RHEL 6" as the default
> basis for derived distros. Once RHEL 7 and CentOS 7 were generally
> available, that assumption became problematically wrong (e.g. systemd
> wasn't a Fedora only feature any more), so the templates were all
> rewritten to be based on operating system feature flags instead (which
> had the added bonus of also making them more tolerant of Fedora
> derivatives).
> 
> I see the seeds of a similar problem being planted with the above
> proposal: what happens when, at some point in the future, "Python 3 as
> default" is no longer a Fedora-only feature? Do we have to go edit all
> the spec files again?

Yikes! Good point, I have put much thought into the macro solution and I wasn't giving enough thought to writing the actual condition...

> What if, instead, we were able to add a new macro that let folks
> *explicitly* opt in to running in the "system Python", but then define
> the recommended spec file usage such that it falls back to Python 2 if
> the "system Python" macro isn't defined?
> 
> That would give people 3 explicit options to choose from:
> 
> * always run in Python 2
> * always run in Python 3
> * run in the same Python as Anaconda and yum
> 
> Single source Python 2/3 compatibility could then be made a policy
> requirement for packages opting in to running in the system Python
> rather than explicitly running in Python 3.

I've thought of this, but the problem is that we'd need to add this new macro to either RHEL's python-devel or minimal EPEL buildroot. We need this because the macros for BuildRequires need to be resolved in the minimal buildroot - so if the macro is not there, RPM can't expand BuildRequires and the build fails. The fact that adding such macros to RHEL's python-devel or EPEL buildroots is not likely made me come up with the proposed approach.

Unless...
Unless we use the original unversioned %__python/%python_sitelib/%python_sitearch macros for this. The downside is that we'd need to go through tons of Fedora python-* specfiles and replace usage of unversioned macros by the versioned ones - but that's one-time effort. The upside is that these work in RHEL/EPEL without any additional effort *and* they kind of express precisely what we want them to express - *the* Python.

I do agree with Nick's 3 explicit options listed above - the first two being mostly for python-* extension packages and the third for applications that "don't care". I think that this is possibly a huge change that would be possible for F23 soonest, but it makes sense (it'd require changes in hundreds, maybe thousands of Fedora specfiles and also in RPM). I still think this only makes sense to use for "applications", not for "libraries", but I guess we're on the same page with this :)

Slavek

> Regards,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia