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
%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.
Thoughts?
Thanks,
Slavek
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
