Re: [PATCH 3/7] configure: Look for auxiliary Python installations

[Eric Blake]

On Thu, Feb 09, 2023 at 10:40:30AM -0500, John Snow wrote:
> At the moment, we look for just "python3" and "python", which is good
> enough almost all of the time. But ... if you are on a platform that
> uses an older Python by default and only offers a newer Python as an
> option, you'll have to specify --python=/usr/bin/foo every time.
> 
> We can be kind and instead make a cursory attempt to locate a suitable
> Python binary ourselves, looking for the remaining well-known binaries.
> 
> This configure loop will prefer, in order:
> 
> 1. Whatever is specified in $PYTHON
> 2. python3
> 3. python
> 4. python3.11 down through python3.6

Makes sense.


>  python=
> +first_python=
>  explicit_python=no
> -for binary in "${PYTHON-python3}" python
> +# A bare 'python' is traditionally python 2.x, but some distros
> +# have it as python 3.x, so check in both places.
> +for binary in "${PYTHON-python3}" python python3.{11..6}

This does not match your commit message. If $PYTHON is set but fails,
you never check python3.  Pre-existing, but now that you're calling it
out as intended, it may be better to write the list prefix as:

for binary in $PYTHON python3 python ...

except that it mishandles $PYTHON containing space, so you want the
quotes, but you don't want to test an empty binary or waste time
testing python3 twice, so more precise could be:

for binary in "${PYTHON-python3}" ${PYTHON:+python3} python ...

Meanwhioe, your use of {11.6} is a bashism, but configure is /bin/sh.
It would be nice if you could use $(seq -f python3.%g 11 -1 6), but
that's probably too specific to GNU Coreutils and won't work on other
platforms; and open-coding it in a shell loop isn't going to be any
prettier.  So you'll be safest if you just manually spell it out:

python3.11 python3.10 ...

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org