Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

----- Original Message -----
> 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.

I guess that I interpreted it my way since I didn't see any "must" in there... But ok, thanks for the clarification :)

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

Right, I guess I'll just agree on disagreeing with you on this :) I don't think it's a problem the same way I don't think "from __future__ import unicode_literals" is a problem.

> > - 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 will. Do you have any idea who I should talk to regarding EPEL? Is it also Dennis?

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

For me, introducing yet another set of macros is unnecessary. I think that it'd introduce a long(-ish) new part of guidelines that'll make them even more complicated than they are right now (compared to one new macro function and rules on how/when to use it).

> -Toshio

Slavek