qemu-devel
[Top][All Lists]
Advanced

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

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


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

Eduardo Habkost <address@hidden> writes:

> On Wed, Nov 07, 2018 at 01:45:35PM +0000, Peter Maydell wrote:
>> On 7 November 2018 at 12:49, Eduardo Habkost <address@hidden> wrote:
>> > Now, why do we need --with-python, and why do we need to use
>> > $(PYTHON) when running tests?  If somebody wants to use a
>> > different Python binary when running tests, they can already use
>> > $PATH for that.
>> >
>> > (That's the same argument I used for iotests a while ago:
>> > https://www.mail-archive.com/address@hidden/msg566631.html)
>> 
>> I'm not a great fan of requiring the user to mess with their PATH
>> to get configure to work. Also, the first python on the path
>> might be the wrong one, and we don't pass PATH from configure
>> to make so you end up having to make sure you specify it
>> right in both places.
>
> You're assuming that this will actually require some people to
> mess with their $PATH because they currently don't have Python on
> their $PATH.  I don't see any evidence that this is expected to
> happen.  Do you?

What makes Python so special we must provide special means to find
it off the PATH?  Why not other tools?

>> Plus we already have --with-python, so if you want to drop
>> it you need to deprecate it first, and you need a justification
>> that's strong enough to outweigh breaking users' existing
>> build/packaging setups and scripts...
>
> I would really like to remove the option as soon as we start
> requiring Python 3.  Let's stop reinventing solutions to problems
> already addressed by PEP 394.

Concur.

We should use python3 wherever we need a Python 3.  There's no point in
letting configure check whether python3 is actually Python 3.

We should use python2 wherever we need a Python 2.  This case needs to
go away (if it isn't gone already).

We may use any of python3, python, python2 wherever we can work with
both Python 3 and 2.  Simply using python3 works on sufficiently recent
hosts.  For maximum portability, we can let configure try python3, then
python.  I wouldn't bother trying python2 as well.



reply via email to

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