All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Michael Roth" <michael.roth@amd.com>,
	"Thomas Huth" <thuth@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Beraldo Leal" <bleal@redhat.com>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH v3 1/6] configure: Look for auxiliary Python installations
Date: Tue, 21 Feb 2023 17:54:57 +0000	[thread overview]
Message-ID: <Y/UFcYRURhYYQwD4@redhat.com> (raw)
In-Reply-To: <CAFn=p-YhFYezskW2Z6G56HXVSGg+S5pcxdmU3CTF7+EpoYvO4w@mail.gmail.com>

On Tue, Feb 21, 2023 at 12:37:43PM -0500, John Snow wrote:
> On Tue, Feb 21, 2023, 6:03 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 2/21/23 02:24, 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.
> > >
> > > As a courtesy, we can make a cursory attempt to locate a suitable Python
> > > binary ourselves, looking for the remaining well-known binaries. This
> > > also has the added benefit of making configure "just work" more often
> > > on various BSD distributions that do not have the concept of a
> > > "platform default python".
> > >
> > > This configure loop will prefer, in order:
> > >
> > > 1. Whatever is specified in $PYTHON
> > > 2. python3
> > > 3. python (Which is usually 2.x, but might be 3.x on some platforms.)
> > > 4. python3.11 down through python3.6
> > >
> > > Notes:
> > >
> > > - Python virtual environments provide binaries for "python3", "python",
> > >    and whichever version you used to create the venv,
> > >    e.g. "python3.8". If configure is invoked from inside of a venv, this
> > >    configure loop will not "break out" of that venv unless that venv is
> > >    created using an explicitly non-suitable version of Python that we
> > >    cannot use.
> > >
> > > - In the event that no suitable python is found, the first python found
> > >    is the version used to generate the human-readable error message.
> > >
> > > - The error message isn't printed right away to allow later
> > >    configuration code to pick up an explicitly configured python.
> > >
> > > Signed-off-by: John Snow <jsnow@redhat.com>
> > > ---
> > >   configure | 34 ++++++++++++++++++++++++++--------
> > >   1 file changed, 26 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index cf6db3d5518..6abf5a72078 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -592,20 +592,40 @@ esac
> > >
> > >   : ${make=${MAKE-make}}
> > >
> > > -# We prefer python 3.x. A bare 'python' is traditionally
> > > -# python 2.x, but some distros have it as python 3.x, so
> > > -# we check that too
> > > +
> > > +check_py_version() {
> > > +    # We require python >= 3.6.
> > > +    # NB: a True python conditional creates a non-zero return code
> > (Failure)
> > > +    "$1" -c 'import sys; sys.exit(sys.version_info < (3,6))'
> > > +}
> > > +
> > >   python=
> > > +first_python=
> > >   explicit_python=no
> > > -for binary in "${PYTHON-python3}" python
> > > +# Check for $PYTHON, python3, python, then explicitly-versioned
> > interpreters.
> > > +for binary in "${PYTHON-python3}" ${PYTHON:+python3} python \
> > > +                                  python3.11 python3.10 python3.9 \
> > > +                                  python3.8 python3.7 python3.6
> >
> > I think if PYTHON is set we shouldn't look at anything else.
> >
> > Paolo
> >
> 
> PYTHON is one we made up, right?

$PYTHON is explicitly set in all our dockerfiles. We should
ensure we honour it and not fallback to anything else when
it is set. ie it would be a user error to set it to point
to a python that is missing/broken, so the user should
expect an error, not fallback to another version.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-02-21 17:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  1:24 [PATCH v3 0/6] Python: Drop support for Python 3.6 John Snow
2023-02-21  1:24 ` [PATCH v3 1/6] configure: Look for auxiliary Python installations John Snow
2023-02-21 11:03   ` Paolo Bonzini
2023-02-21 17:37     ` John Snow
2023-02-21 17:54       ` Daniel P. Berrangé [this message]
2023-02-24 18:04     ` Eric Blake
2023-02-21  1:24 ` [PATCH v3 2/6] configure: Add courtesy hint to Python version failure message John Snow
2023-02-21  7:33   ` Philippe Mathieu-Daudé
2023-02-21 11:01   ` Paolo Bonzini
2023-02-21  1:24 ` [PATCH v3 3/6] DO-NOT-MERGE: testing: Add Python >= 3.7 to Centos, OpenSuSE John Snow
2023-02-21  1:24 ` [PATCH v3 4/6] DO-NOT-MERGE: testing: add pip-installed sphinx-build to CentOS 8 John Snow
2023-02-21  1:24 ` [PATCH v3 5/6] meson: prefer 'sphinx-build' to 'sphinx-build-3' John Snow
2023-02-21  6:50   ` Markus Armbruster
2023-02-21 16:49     ` John Snow
2023-02-22  7:14       ` Markus Armbruster
2023-02-23  4:40         ` John Snow
2023-02-23  6:13           ` Markus Armbruster
2023-02-23  8:53           ` Paolo Bonzini
2023-02-21 11:31   ` Paolo Bonzini
2023-02-21 12:37     ` Paolo Bonzini
2023-02-21 16:56     ` John Snow
2023-02-21  1:24 ` [PATCH v3 6/6] Python: Drop support for Python 3.6 John Snow
2023-02-21  7:11   ` Markus Armbruster
2023-02-21  7:00 ` [PATCH v3 0/6] " Markus Armbruster
2023-02-21 11:33   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/UFcYRURhYYQwD4@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.