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

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

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

Seconded.  This is not about the cost of maintaining existing
compatibility gunk, it's about the extra effort to first get the
remainder to work with 2 and 3, only to throw away 2 a few months later.

I propose we permit ourselves to port stuff that isn't essential to
building QEMU straight to 3 instead.  This includes iotests.

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

It's worth doing only if the benefits of doing it outweigh the costs.  I
don't think they do.