[issue35872] Creating venv from venv no longer works in 3.7.2

Paul Moore added the comment: See https://github.com/pypa/virtualenv/issues/1339 - it's possible that something in this area is still affecting virtualenv. -- ___ Python tracker

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower added the comment: New changeset 44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch '3.7': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4cfe8ddd67ed --

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- pull_requests: +11689, 11690, 11691 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- pull_requests: +11689 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- pull_requests: +11689, 11690 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower added the comment: New changeset a8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch 'master': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea67840779b9351f --

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower added the comment: > I don't know why we add argv0_path to sys.path. My guess is that the idea was to be able to load the .pyd files we used to put alongside it, though we found out they weren't being loaded anyway. One potential side effect is that manually created .pth files

[issue35872] Creating venv from venv no longer works in 3.7.2

Eryk Sun 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

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- keywords: +patch, patch, patch pull_requests: +11667, 11668, 11669 stage: -> patch review ___ Python tracker ___

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- keywords: +patch pull_requests: +11667 stage: -> patch review ___ Python tracker ___ ___

[issue35872] Creating venv from venv no longer works in 3.7.2

Change by Steve Dower : -- keywords: +patch, patch pull_requests: +11667, 11668 stage: -> patch review ___ Python tracker ___ ___

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower 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? My proposed fix for issue35873 (PR soon) is going to make this trivial. -- nosy:

[issue35872] Creating venv from venv no longer works in 3.7.2

Eryk Sun added the comment: > You can't actually nest virtual environments, at least with venv Yes, they can't be nested in terms of inheriting site-packages. But the "home" value in this case references the creating environment, which hasn't changed from previous versions. It's the same in

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower added the comment: You can't actually nest virtual environments, at least with venv - it ought to be configuring it all against the original environment. What is in your pyvenv.cfg files here? -- ___ Python tracker

[issue35872] Creating venv from venv no longer works in 3.7.2

Eryk Sun added the comment: > This scenario should work, as running the other venv's redirector > will update the variable. The order gets reversed. In the simple case where we have two launchers, the launcher for the nested virtual environment executes the launcher for the outer (creator)

[issue35872] Creating venv from venv no longer works in 3.7.2

Steve Dower added the comment: This scenario should work, as running the other venv's redirector will update the variable. The nearly identical report in issue35873 is apparently launching "default" Python, but presumably without clearing the variable. Since I can't tell what's going wrong

[issue35872] Creating venv from venv no longer works in 3.7.2

Eryk Sun added the comment: The __PYVENV_LAUNCHER__ variable gets set by each launcher instance. We get one launcher process for every level of nesting, and the last launcher to run sets the final value that will be seen by the real python.exe. Possibly the launcher could resolve the home

[issue35872] Creating venv from venv no longer works in 3.7.2

New submission from Marc Schlaich : Creating a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base