----- Original Message -----
On 27 January 2015 at 21:26, Bohuslav Kabrda
<bkabrda(a)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(a)gmail.com | Brisbane, Australia