Re: [PATCH 1/1] configure: prefer python's sphinx module
On Fri, 19 Jun 2020 at 18:57, John Snow <jsnow(a)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" ?
thanks
-- PMM