Apps using default Python in Fedora vs. EPEL

Bohuslav Kabrda bkabrda at
Tue Jan 27 11:26:26 UTC 2015

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
%global default_python python

%make_default_python %default_python

- The %make_default_python macro function will point all the unversioned macros to proper values for given %default_python:

### In Fedora
%{__python}        -> /usr/bin/python3
%{python_sitelib}  -> /usr/lib/python3.X/site-packages
# and other macros...

### In EPEL
%{__python}        -> /usr/bin/python2
%{python_sitelib}  -> /usr/lib/python2.X/site-packages
# and other macros...

- This means that packagers will be able to use the unversioned macros throughout their specfile. Requires and BuildRequires will look like this:

Requires:     %{default_python}-flask
BuildRequires %{default_python}-setuptools

Note: since BuildRequires need to be expanded in the minimal buildroot, it's necessary to define the %default_python macro in the specfile. Other way would be to define it in a macro file that would be added to the minimal buildroot, but that's neither very likely nor very nice :)

I think this solution makes sense for *applications* that need to be built both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3 proposal [1], in case such an app was to be moved to python3X in EPEL (%default_python would just be redefined to "python3X"). I also think that this approach should never be allowed for packaging "libraries", e.g. packages that have python-foo and python3-foo subpackages.



More information about the python-devel mailing list