On 29 January 2015 at 07:39, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> wrote:
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).----- Original Message -----
> On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> wrote:
> > ----- Original Message -----
> >> On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač <mitr@xxxxxxxxxx> 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.
> 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.
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.
> >> >> - 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.
The problem is one of communication and trying to get out of your head a 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.
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.
Does that help clarify?
Stephen J Smoogen.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
