Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

----- Original Message -----
> On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> > ----- Original Message -----
> >> On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač <mitr at redhat.com> wrote:
> >> > (Speaking only for myself, not for all of FESCo; hoping others will
> >> > chime
> >> > in.)
> >> >> - What if Anaconda does make it? :)
> >> > I don’t know.
> >>
> >> I'm skeptical that will happen.  Even if it does, that alone is likely
> >> not enough to claim python3 by default.  You need all the basic
> >> functionality to work with pthon3, e.g. yum and dnf would also need to
> >> be ported.
> >
> > DNF works with Python 3, Yum will never work with it (this is why the
> > change page says that this feature depends on DNF becoming the default
> > package manager). I'm regularly talking to some of Anaconda devs (mostly
> > Vrata Podzimek) and they still think this is doable *without* introducing
> > high number of regressions, that would be impossible to fix before F22
> > final.
> 
> Good to know DNF is already fine in regards to python3.  I must have
> misunderstood the references to python3-dnf yesterday.  I was under
> the impression that it was something that existed, but wasn't widely
> used or tested at this point.  It certainly didn't seem to be the
> default dnf that everyone is using in F20/F21 (and rawhide today)
> installs.

Not sure about it being the default, but we've been testing it in DevAssistant for dependency installation on Python 3 and never encountered any problems. I was also contacted by dnf maintainer with a question on how to switch "dnf" to use "python3-dnf" (package-wise), so I guess that's what will be done for F22 (but that's just my guess, dnf maintainer would have to comment here).

> Even still, that hinges on DNF being the default package manager in
> F22.  There are some concerns that it won't make it due to rel-eng
> tooling used to compose the images, etc.  If that's the case, yum will
> still be required.

Required, yes, but we'll still have tons of packages built with Python 2. I never said that porting rel-eng tooling is the goal for F22.

> > What else is "all basic functionality"? If this is about making Workstation
> > LiveCD python2-free, then I'm not sure we can make that even for F23
> > (samba and glusterfs will be hard nuts to crack, although the work on
> > samba has already started).
> 
> That might be a good goal, but it wasn't what I was thinking.  I was
> thinking more along the lines of a more minimal install only requiring
> python3 to be installed.  I don't have a concrete package set in mind
> at the moment.

So if more minimal is minimal buildroot, then we can achieve that, since it only has python-libs because of gdb and gdb can be rebuilt with Python 3 (upstream source is compatible). If that means minimal cloud image, then we can do it (we're waiting for the cloud-init folks to accept the py3 patches, which should happen any time now). If that means content from fedora-live-base.ks, then we can do pretty much everything, except of samba (I think) - and Petr Viktorin is doing some talking to people to get rid of samba from this config, because it seems to be unnecessary there.

> >> >> - What is "enough"? It's possible that two or three packages may be
> >> >> still
> >> >> unported even in F23 (and as for server livecd in F23, I think there
> >> >> will
> >> >> be
> >> >> few more).
> >> > 2-3 packages should not be an issue, perhaps unless they were very
> >> > visible
> >> > (e.g. having a public and widely-used Python plugin API).
> >> >
> >> >> - So is it ok if I file bugs for all components that I know are
> >> >> upstream-compatible with Python 3 (bugs to get them switched, I mean)?
> >> >
> >> > If we are shipping both Python versions anyway, and the specific
> >> > packages
> >> > are known to be compatible (i.e. there little risk), I don’t see any
> >> > reason not to switch them already in F22.
> >>
> >> I agree with everything Mirek said, as well as his take on the FESCo
> >> reasoning.
> >>
> >> We'd really like to see this happen, we don't want to slow down the
> >> work.  We just don't feel F22 is a release that is going to accurately
> >> reflect the python3 as default status.
> >
> > What I'm afraid is that by postponing this change, we will have achieved
> > nothing else, than half more year of status quo.
> 
> That's understandable, and to be honest a good concern.  At the same
> time, just declaring something as "default" when reality doesn't
> reflect that really won't achieve the actual goal either.  FESCo is
> hoping that opening the bugs against rawhide after F22 branching will
> help prod things along.  We'll be happy to revisit at that point and
> see if there are other efforts we can help with to make this happen in
> F23.

Considering all the information mentioned above and assuming Anaconda makes it, I'd say it should be perfectly possible to declare Python 3 the default. As for the packages that are not in the minimal installs, I can always open bugs for them before beta and only those maintainers who believe it to be safe can switch.

> josh
> --

Thanks,
Slavek