Eryk Sun <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue35872>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
