- Original Message -
> On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> > Hi all,
> > as a new Fedora Python maintainer, I have set myself a goal of moving
> > Fedora to Python 3 as a default.
>
> I'm not sure we want to make python3 default depending on what your
> definition of default is.
>
> /usr/bin/python should refer to python2 --
> http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this
>
So, my definition of default is "all system tools use Python 3, it is the only
Python that gets to minimal buildroot/minimal Fedora installation" - that means:
- livecd can still ship Python 2
- /usr/bin/python points to Python 3
- Please note, that the pep you're referring to also states that "python
should refer to the same target as python2 but may refer to python3 on some
bleeding edge distributions", so this wouldn't really be going against the pep.
> The python package itself should probably also remain python2 due to
> dependencies and expectations from other distros and documentation --
> I think I'd be -1 to changing this
>
> The Fedora live images contain only python3, not python2 -- I'd be heavily
> in favour of this. +1
>
> > This is going to be a multirelease effort
> > that is going to affect lots of Fedora parts. Since we will need to switch
> > default package manager from Yum to DNF (which is supposed to work with
> > Python 3), we will need to wait for that. I've been told that DNF should
> > be default in F22, so that's my target, too. That should also give
> > everyone else plenty of time to work on other essential packages to make
> > this happen.
>
> Getting there at the same time as we get to DNF sounds like a good timeline.
> (But see my note on anaconda below). +1
>
> > Here is my analysis/proposal:
> > Before switching, we need to make sure that everything "important" (*) is
> > Python 3 compatible. There are three steps I see in this transition:
> > 1) Getting rid of Python 2 in mock minimal buildroot.
>
> I'm not sure about this one as it will cause a lot of package churn. It
> might be a necessary pain pointi or it might be a pain point we want to
> defer until later in our porting efforts. Have to think about it more.
>
If you look at the minimal mock buildroot for rawhide now, the only thing that
is drawing in Python is gdb because of it's Python bindings (if I'm not
mistaken). So compiling GDB against Python 3, which should work with newest
gdb, will accomplish this AFAICS.
> > 2) Porting Anaconda to Python 3.
>
> +1 -- unfortunately, this probably depends on DNF So we may need to push
> DNF in F22 and anaconda compatible with python3 in F23.
>
DNF is a continuous effort. I believe that DNF will provide it's Python 3
bindings sooner than in F22, so Anaconda devels can simultaneously do porting
to Python 3 as well as to DNF. IMO this is good thing, since they will just do
one big rewrite instead of two smaller.
> > 3) Making all livecd packages depend on Python 3 by default (and eventually
> > getting rid of Python 2 from livecd) - this will also require switching
> > from Yum to DNF as a default, that is supposed to support Python 3.
>
> +1 -- this is what I see as the eventual goal (or perhaps, livecd python2
> free followed by DVD python2 free followed by distro python2 free).
>
>
> 3.5) Switch tools that could target either python2 or python3 to target
> python3. Currently the packaging guidelines say to target python2 to
> control dep proliferation and because that's the most supported by the
> larger python ecosystem. We should switch the recommendation when our
> minimal environment must have python3 but does not need to have python2.
>
IMO we should switch this for F21, since livecd ships Python 3 anyway, so the
switch doesn't have to happen in one point, but can be continuous.
> > ( 4) Making as much of the remaining packages Python 3 compatible )
> >
>
> We could talk quite a bit on this point -- How active do we want to be with
> the things that aren't in one of the essential buckets from further up. We
> could defer thinking about this until after we get the livecd python2-free,
> though.
>
This is really the last step, that is somehow tied what you mentioned as a
reaction to 3) - going through the rest of packages on DVD and then whole
distro. This will take few more releases I guess, but it is not that important
as sorting out livecd.
> > In past few days, I've been going through packages that are part of the
> > above steps. I have reported numerous bugs asking upstream and/or Fedora
> > maintainers for help with porting to Python 3. We have some spare cycles
> > in our small Python packaging team, that we will try to provide to whoever
> > needs them most, but we're limited and we'll have to rely on the upstreams
> > to do most of the work. I'm attaching a document with list of packages
> > that need porting with some notes/links to opened bugs. Sometime soon,
>
