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

Reply via email to