Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
> 
> Current state:
> - Up until F21, maintainers were encouraged to build applications with Python 2, but weren't discouraged from building with Python 3.

Note -- this isn't quite right.  If an application could run with either
python2 or python3 maintainers in F21 and below were supposed to have the
app run with python2.  F22 is supposed to flip this so that maintainers are
supposed make these packages run with python3 instead of python2.

> - 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...
> 
I'm not really a fan of redefining existing macros like this.  The problem
is the same as the python2 "from __future__ import unicode_literals"
statement.  It causes your existing knowledge of how things work to betray
you.  And recognizing that the change is present requires you to look
somewhere far away from the code that you are actually interested in.

> - 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 :)
> 
Have you talked to dennis?  We've added packages to the minimal BuildRoot
many times before in order to enable macro files.  Not so problematic if
it's only one macro, though.

> 
> 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?

If we were to use different macro names instead of overwriting currently
well known ones I think this has merit.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20150127/d8792126/attachment-0001.sig>