On Fri, 19 Jun 2020 at 18:57, John Snow <jsnow@xxxxxxxxxx> 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
