[PATCH 1/1] configure: prefer python's sphinx module

Peter Maydell peter.maydell at linaro.org
Fri Jun 19 19:09:46 UTC 2020

On Fri, 19 Jun 2020 at 18:57, John Snow <jsnow at redhat.com> wrote:
> On 6/18/20 5:56 AM, Peter Maydell wrote:
> > How do I use the system python but a venv sphinx-build? At the
> > python3 -m venv myvenv
> > cd myvenv/bin
> > ls -l python*
> lrwxrwxrwx. 1 jsnow jsnow  7 Jun 19 13:23 python -> python3*
> lrwxrwxrwx. 1 jsnow jsnow 16 Jun 19 13:23 python3 -> /usr/bin/python3*
> The venv uses symlinks, so it will continue to use your system version,
> but you can install sphinx here.
> I'm proposing you do either one of:
> A) ./configure --python=/home/petmay01/python-env/bin/python3
> B) source ~/python-env/bin/activate
>    ./configure

This seems strictly worse than what we have now (where I can
just tell configure to use the sphinx-build I want it to).
I don't want to do A because I'd rather just use the system
python, and I don't want to use B because it requires an
entire extra step (and also I think it will end up using the
python from the venv rather than the one from the system).

> > moment I can easily do that with
> >   --sphinx-build=/home/petmay01/python-env/bin/sphinx-build
> > because scripts inside a venv have #! lines that make them
> > work without having to manually activate the venv. I don't
> > want to have to use some random non-system Python just
> > because I have a newer Sphinx.
> >
> I was under the impression that it would be best if sphinx was executed
> using the user's specified python binary instead of allowing
> scripts/qapi to run under the user's python but sphinx to run under a
> different python.

I'm not sure that's right. We should run sphinx with whatever
python it wants to run as, not feed it something different
it doesn't expect.

> One of the reasons I came to this belief was to ensure that when
> operating inside of a venv that QEMU was always using that venv's python
> and sphinx instead of "leaking" out to the system's installation. It
> felt more explicit.

Well, if we're in a venv then by default it makes sense for us
to be using the venv's setup.

> A problem with looking for 'sphinx-build-3' and 'sphinx-build' entry
> scripts is that the /usr/bin/xxx namespace is shared between python2 and
> python3 packages and we may wind up selecting a sphinx for the wrong
> python version entirely -- and from what I could tell, there wasn't a
> way to interrogate sphinx to get it to tell us what python it was using,
> or any other way to force this kind of scripted entrypoint to use *my*
> python.

configure's checks should mean we reject a sphinx-build
that uses a too-old python, though.

> Fedora gets into trouble here because we want 'sphinx-build-3', but this
> ignores our venv version because the script entrypoint in a venv is
> 'sphinx-build' -- which might be the system's python2 version.

Mmm. That seems to me like it's basically Fedora having made a
mistake :-) Maybe we should say "try sphinx-build, if that
exists and works then great, otherwise try sphinx-build-3 next" ?

-- PMM

More information about the libvir-list mailing list