qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH] tests: Fix Python 3 detection on o


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] tests: Fix Python 3 detection on older GNU make versions
Date: Mon, 12 Nov 2018 10:07:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Max Reitz <address@hidden> writes:

> On 08.11.18 13:43, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <address@hidden> writes:
>> 
>>> Hi Markus,
>>>
>>>
>>> Le jeu. 8 nov. 2018 09:46, Markus Armbruster <address@hidden> a écrit :
>>>
>>>> Cleber Rosa <address@hidden> writes:
>>>>
>>>>> On 11/7/18 1:05 AM, Markus Armbruster wrote:
>> [...]
>>>>>> PEP 394 recommends software distributions install Python 3 into the
>>>>>> default path as python3, and users use that instead of python, except
>>>>>> for programs that are source compatible with both 2 and 3.  So, is
>>>>>> finding out whether python is a Python 3 really appropriate?  Why can't
>>>>>> we just use python3 and be done with it?
>>>>>>
>>>>>
>>>>> I mentioned that before, when you pointed out the issue you fix here,
>>>>> that configure may be the best place to get the Python version (not only
>>>>> the major version) and make it available elsewhere.  Even if not used
>>>>> for other purposes, it is IMO important information to show on the
>>>>> resulting "configure" output.
>>>>>
>>>>> I'm sending patches to do that in a few.
>>>>>
>>>>>> If we can't: isn't this a configure problem?
>>>>>>
>>>>>
>>>>> I believe adhering to PEP394 is a good thing, but even that document
>>>>> recognizes that the real world is not a perfect place: "however, end
>>>>> users should be aware that python refers to python3 on at least Arch
>>>>> Linux".  And it only covers *nix systems, so if we hope to care for
>>>>> non-*nix systems, we have to check the Python version manually.
>>>>>
>>>>> So, I guess the safest approach from QEMU's side is to check for the
>>>>> version indeed.
>>>>
>>>> If somebody can point to a system people still use where python3 doesn't
>>>> get you a Python 3, but python does, catering for such (crappy) systems
>>>> in configure makes sense.  Until then, it's a waste of brain waves and
>>>> configure run time.
>>>>
>>>> PEP 394 mentions Arch Linux.  It's been seven years.  What's the most
>>>> recent version of Arch Linux that's still crappy in this regard?
>>>>
>>>
>>> Arch doesn't provide python2 by default, thus python points to python3.
>> 
>> That's non-crappy as long as python3 also exists, as PEP 394 recommends.
>> Does it?
>
> Sure it does.
>
> Arch is just problematic in how it handles "python" itself.  I don't
> think there is any system that has Python 3 but no "python3".

Bottom line: we can safely assume that a host that has Python 3 provides
it as python3.

Corollary:

* When python3 doesn't exist, checking whether python is Python 3 is
  futile.

* Checking whether python3 really is Python 3 is silly.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]