Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

----- Original Message -----
> On 27 February 2015 at 11:02, Toshio Kuratomi <a.badger at gmail.com> wrote:
> >
> > On Feb 25, 2015 3:14 PM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> >
> >> For those not following along with the FPC ticket, Toshio and Tomspur
> >> have a nice write-up of the options at
> >> https://etherpad.mozilla.org/2Uqk0ikCll
> >>
> >> I came back to this question myself due to a couple of different
> >> ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19
> >>
> >> * How does the situation in Fedora change if the upstream PEP 494
> >> recommendation to downstream Linux distros was to change in
> >> conjunction with the Python 3.5 release currently scheduled for
> >> September? That release (https://www.python.org/dev/peps/pep-0478/)
> >> amongst other things, automatically handles EINTR errors for syscalls,
> >> restores binary interpolation support and adds matrix multiplication
> >> support and os.scandir().
> >>
> >
> > I would be against making the switch to /usr/bin/python at this time but
> > would do most of that fighting upstream.  If the pep were updated then I'd
> > at least want to see that the other major distros are committed to changing
> > their /usr/bin/python at the same time.
> >
> > Changing the behavior of a well known program like this is a bad idea.  As
> > it breaks compatibility: with people's home grown scripts, with their self
> > installed programs, and between os's and os releases. The pep is palatable
> > because the arguments in favor of someday changing the value revolve around
> > someday there not being a /usr/bin/python on most systems. At that point it
> > becomes reasonable to reallocate /usr/bin/python and let the systems where
> > /usr/bin/python be declared legacy and the behavior of /usr/bin/python on
> > those legacy systems is the quirk, not ours.
> >
> > We could cut over sooner than this argument actually makes the case for but
> > now is definitely not that day.  Fedora, rhel, ubuntu, aren't yet at the
> > point where /usr/bin/python isn't present on most of their installed
> > systems
> > in their latest version, let alone all of their versions.people are still
> > pulling /usr/bin/python onto their systems through dependencies for common
> > applications even if their os is advanced enough not to need it by default.
> > We have quite a ways to go before /usr/bin/python can be switched.
> 
> Yeah, that's fair - a staggered release with the distros switching
> first before end user scripts makes sense. That would make the likely
> target date for a PEP 394 update some time in early 2017 with Python
> 3.6.
> 
> We could *potentially* switch the recommendation some time in 2016 if
> all goes well with the distro migrations and significant libraries
> start dropping Python 2.7 support, but switching in conjunction with
> Python 3.5 would still be too soon.

+1 to switch with Python 3.6. PEP 394 should however be made to reflect this ASAP - I mean it should be made to say that this change will happen with Python 3.6. The sooner it says that, the more time for people to notice it and more time for distros to prepare.

> >> * With the default interpreter change postponed to Fedora 23, would it
> >> make sense to patch the system Python in Fedora 22 to emit Python 3
> >> warnings by default when it was run using the unqualified "python"
> >> reference rather than being run as the qualified "python2"? And then
> >> switch the symlink along with the RPM macros in Fedora 23?
> >>
> >
> > No to switching the value of /usr/bin/python and stated above.  The test
> > makes some sense. If your warning is restricted to warning not to use
> > /usr/bin/python (use /usr/bin/python 2 instead) that sounds really good to
> > me.  (Your wording sounded like we should turn on warnings like python2 -3
> > does which I don't think is such a good idea for fedora 22 but might be
> > good
> > in the future... our perhaps, like the kernel does with extra kernel
> > debugging, we should turn it on in rawhide and fedora.n+1 but turn it off
> > before release.)
> 
> I did mean the latter (turning on -3 warnings), but I like your idea
> of only doing that in Rawhide and the Alpha releases for F23, and then
> switching to a simple "use a qualified Python reference" warning in
> the Betas and the actual release.

I'm also +1 on emitting a warning about /usr/bin/python usage, although I'm almost sure that will break something. There are always apps that expect certain form of subprocess output etc - and this will break them. IMO this should only be done in F23, not in F22 which is already in alpha.
I'm assuming that there is no builtin configure option to emit this warning and we'd have to patch this ourselves, is that right or have I just missed such option?

> >> It's also worth noting that the change I am considering to the
> >> upstream recommendation would place a qualifier on the distro
> >> providing a C.UTF-8 locale, so the "C.UTF-8 in upstream glibc" RFE
> >> (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a
> >> key enabler for making the symlink switch in Fedora (associated Fedora
> >> RFE: https://bugzilla.redhat.com/show_bug.cgi?id=902094)
> >>
> > Like tomspur I'm not sure I see the specific relevance of this to what
> > /usr/bin/python invokes although I would welcome the change :-)
> 
> Being able to type "LANG=C.UTF-8" instead of "LANG=C" fixes some of
> the odd corner cases where the interpreter startup sequence gets
> confused. However, I remembered that subtle issues aren't the ones
> we're worried about here - it's the big noisy ones like legacy print
> and exec statements.

FWIW, I would also welcome this change (and yeah, "I want my print statement back" is the most often complain that I've heard so far ;))

> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

Thanks,
Slavek