----- Original Message -----
On 29 January 2015 at 07:39, Bohuslav Kabrda < bkabrda(a)redhat.com
> ----- Original Message -----
> > On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda < bkabrda(a)redhat.com >
> > wrote:
> > > ----- Original Message -----
> > >> On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač < mitr(a)redhat.com
> > >> wrote:
> > >> > (Speaking only for myself, not for all of FESCo; hoping others
> > >> > 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
> > >> 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
> > >> 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
> 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
> will be done for F22 (but that's just my guess, dnf maintainer would have
> comment here).
> > Even still, that hinges on DNF being the default package
> > 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
> 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
> > >> >> there
> > >> >> will
> > >> >> be
> > >> >> few more).
> > >> > 2-3 packages should not be an issue, perhaps unless they were
> > >> > 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
> > >> >> upstream-compatible with Python 3 (bugs to get them switched,
> > >> >> 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
> > >> > 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
> > >> work. We just don't feel F22 is a release that is going to
> > >> 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
> it, I'd say it should be perfectly possible to declare Python 3 the
> 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.
The problem is one of communication and trying to get out of your
picture of what you mean that other people can figure out. From what I can
see in this and the other threads.. this is where the problem that FESCO
punted on. They don't know exactly what you mean by "Python3 by default"
especially since lines like that have implications of "No new python
packages will be allowed in Fedora unless they are Python3". I think a clear
list of what python software currently in use that relies on python.
I do agree that this is mostly a communication problem. I honestly never thought that
someone could imply from this that "No new python packages will be allowed in Fedora
unless they are Python3".
Just doing a stupid "yum remove python | egrep -v
'^python|yum' " on my
system I get ~400 packages which rely on python including a couple of perl
ones? Does your definition mean 201 of them will use python3? Or is your
definition different. The problem is that it is clear in you and your teams
head, but doesn't seem to be clear outside of that.
I summed that up at the mail I sent here . That mail contains copy'n'paste
definition of what I mean by "Python 3 as Default" from the Change page. I also
wrote in that mail that we may not reach some of those goals, but I also think that
it's worth to switch as many applications as possible to Python 3 (those that are
Python 3 compatible upstream).
(BTW I think that the numbers you provide are a bit unfair, since I didn't have a
chance to file the bugs for the switch in the first place)
Does that help clarify?
It does help, yes. I'm still missing precise FESCo definition, though. Is it that DNF
and Anaconda would need to be Py3 ported and that would be enough? I think that none of
the FESCo members provided me with a criteria for when they'd say that we do have
Python 3 as default (or I'm failing to see the criteria).
Stephen J Smoogen.