----- Original Message -----
> On 27 January 2015 at 21:26, Bohuslav Kabrda <bkab...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
