Eryk Sun <eryk...@gmail.com> added the comment:
> Is there any reason to not resolve the base executable on creation and > make it relative to that? So the second pyvenv.cfg would have the same > home directory as the first? I was trying to avoid changing the existing behavior of `home` from how it works in 3.6. Your solution will introduce a (probably minor) change, which may be for the best anyway. The computed argv0_path gets added to sys.path, which in the normal case is the installation directory, but it gets overridden by `home`. In 3.6, in the nested-create case, the argv0_path is the creating environment's Scripts directory. For example: C:\>type C:\Temp\test\env36_2\pyvenv.cfg home = C:\Temp\Test\env36_1\scripts include-system-site-packages = false version = 3.6.4 C:\>C:\Temp\test\env36_2\Scripts\python.exe -S Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 >>> import sys >>> print(*sys.path, sep='\n') C:\Temp\test\env36_2\Scripts\python36.zip C:\Program Files\Python36\Lib\ C:\Program Files\Python36\DLLs\ C:\Temp\Test\env36_1\scripts I don't know why we add argv0_path to sys.path. If it's meant to be the directory of the (not necessarily real) executable, then the last path in the above example should be "C:\Temp\Test\env36_2\Scripts" instead of "env36_1\Scripts". If the argv0_path is meant to be the installation directory, as part of the standard library, then it should be "C:\Program Files\Python36". PR 11745 will make it consistently the latter for all virtual environments. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35872> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com