----- 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 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