On 08.01.2020 14:26, Musbur wrote:
Hello,
I'm experimenting with package development on different versions of Python in different virtualenvs. After running "make" I don't do "make install", but rather I set up virtualenvs by running /path/to/source/python -m venv env_dir. This works for as long as I don't need to compile extensions. Once I do that I'm running into trouble because there is no python3-config binary in the venv, so it uses the "system" python3-config which of course returns results for the /usr(/local)/.... tree.
This seems to go against the idea of an encapsulated and self-contained environment. And the venv created straight from the "not-installed" source tree works so well that having a venv/bin/python3-config whose output points into the source tree seems a logical step. Is this an omission or is there a rationale for not doing it?
AFAIK for _inside_ a virtual environment, the convention is `python', `python-<stuff>`, `pip' etc. -- unversioned executables. Versioned executables are the convention for UNIX _outside_ a virtual environment. This is codified in https://www.python.org/dev/peps/pep-0394/.
Of course I can "properly" install different Python versions by using different "configure --prefix" directories. But I like the venv so much in general that this rubs me the wrong way.
Thanks! _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KMG3USMQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Regards, Ivan