Apps using default Python in Fedora vs. EPEL

[Nick Coghlan]

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?

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.

Regards,
Nick.

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