Re: [Qemu-block] [RFC] Require Python 3 for building QEMU

[Kevin Wolf]

Am 15.10.2018 um 12:02 hat Peter Maydell geschrieben:
> On 15 October 2018 at 10:32, Daniel P. Berrangé <address@hidden> wrote:
> > On Sat, Oct 13, 2018 at 02:02:27AM -0300, Eduardo Habkost wrote:
> >> Signed-off-by: Eduardo Habkost <address@hidden>
> >> ---
> >> I'd like to do this in QEMU 3.1.  I think it's time to drop
> >> support for old systems that have only Python 2.
> >>
> >> We still have a few scripts that are not required for building
> >> QEMU that still work only with Python 2 (iotests being the most
> >> relevant set).  Requiring Python 3 for building QEMU won't
> >> prevent people from using those scripts with Python 2 until they
> >> are finally ported.
> >
> > I think it is premature & unecessary to do this. We just got QEMU building
> > with dual Python2/3 in 3.0 to give people leeway in the migration path to
> > a fully v3 future. The code to support building 2/3 in parallel is not
> > imposing a unreasonable maint burden. Dropping py2 suport would have
> > negligible impact on the code, as there's no v3-only features we have
> > used. IOW, I don't think there's a compelling reason to rush into forcing
> > users onto v3.
> >
> > If we want to drop py2, we should give people a warning of such a planned
> > change, especially since some of our targetted host OS[1] don't even
> > include a py3 as standard without acquiring extra add-on repos. Devs in
> > a typical corporate env will not have the freedom to install such extra
> > repos on their machines.
> 
> I agree. I also think that dropping python 2 support before we've
> even converted all our python scripts to handle python 3 is the
> wrong order to do things. People interested in moving forward with
> the transition to python-3-only should start by making sure everything
> we have works with python 3...

It's easier to port stuff to Python 3 though than making them work with
both. I think Eduardo's RFC is in part motivated by a patch from
Philippe that converted something in iotests to work with Python 3,
passed review and then turned out to break Python 2.

Having to test every iotests patch twice with different Python versions
isn't something I would like to do for extended periods of time.

Kevin