Re: [Qemu-devel] [Qemu-block] [PATCH] tests: Fix Python 3 detection on older GNU make versions

[Cleber Rosa]

On 11/8/18 1:26 PM, Eduardo Habkost wrote:
> On Thu, Nov 08, 2018 at 12:36:37PM -0500, Cleber Rosa wrote:
>>
>>
>> On 11/8/18 11:51 AM, Eduardo Habkost wrote:
>>
>>> I'm not sure I agree with the "is an important thing to keep
>>> track of" part.  I don't think we'll have any need to keep track
>>> of the Python version in shell script or makefiles after we start
>>> requiring Python 3.
>>>
>>
>> Well, "Python 3" is not a uniform thing.  There are many changes across
>> the 3.x spectrum that can bite you.  I'm speaking out of the experience
>> with Avocado, that supports Python 3.4, 3.5 and 3.6 (and that reminds me
>> we should add tests for 3.7).
> 
> Do you expect us to need to keep track of the exact Python
> version before running the Python interpreter?  Code written in
> Python doesn't count, because it can simply use sys.version_info.
> 
> 

You're right, Python code can do that.  My proposal is really to
facilitate other parts of the test automation, and as described later,
the debugging on remote systems.

>>
>>> Extra cleanups (like moving version checks to ./configure) are
>>> still welcome, but keep in mind that this will probably be thrown
>>> away once we drop Python 2 support.
>>>
>>
>> I don't think it should.  Let me give the example of a "Python 3.0" job
>> on Travis, related to the following snippet:
>>
>>     # Python builds
>>     - env: CONFIG="--target-list=x86_64-softmmu"
>>       python:
>>         - "3.0"
>>
>> If you look at https://travis-ci.org/clebergnu/qemu/jobs/452033247#L983
>> you'll see that the intended goal was missed.  That has to do with how
>> Travis makes the requested Python version available, and it was only
>> obvious because this branch prints the Python version used.
>>
>> Developers writing Python code, for instance tests, may assume a given
>> API that doesn't exist or behave like they expect, and not knowing the
>> Python version used on a remote environment makes debugging extra hard.
> 
> I'm not sure I get your point.  We can surely add diagnostic
> messages to show the Python version, and we can make ./configure
> fail if Python 3 is unavailable.  I'm talking about adding code
> to ./configure to save Python version info for makefile rules and
> shell scripts.  I expect the extra code to be unnecessary in the
> future.
> 

I'm definitely happy if you agree with printing the Python version,
that's where most of the value is indeed.  Then, if we need to keep the
version in the generate Makefile is something to be seen.

- Cleber.