
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2019-02-01 09:03 byschlamar, last changed2022-04-11 14:59 byadmin. This issue is nowclosed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 11745 | merged | steve.dower,2019-02-03 00:00 | |
| PR 11745 | merged | steve.dower,2019-02-03 00:01 | |
| PR 11753 | merged | steve.dower,2019-02-04 07:22 | |
| Messages (4) | |||
|---|---|---|---|
| msg334659 -(view) | Author: Marc Schlaich (schlamar)* | Date: 2019-02-01 09:03 | |
Controlling a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the changebpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment.This is obviously related tobpo-35872, but this could be a different bug.When a Python script in a venv wants to control another venv by running commands like `another-venv\python.exe -m pip` with subprocess, python.exe is not referencing the other venv. It is referencing to the venv the script currently running from. This is probably because os.environ contains a '__PYVENV_LAUNCHER__' which is pointing to the venv from the script.This can be reproduced with pipx (https://github.com/pipxproject/pipx-app) by running pipx install --python "C:\Program Files (x86)\Python37-32\python.exe" --verbose toxThis results in pip installing to venvs\pipx-app and not in venvs\tox. I assume a simpler reproduction might be (but I cannot check this anymore as I'm back on 3.7.1 right now): C:\Program Files (x86)\Python37-32\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -c "import subprocess; subprocess.run(['C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe', '-m', 'pip', 'install', 'tox'])"Downstream bugreport in pipx ishttps://github.com/pipxproject/pipx-app/issues/81. | |||
| msg334774 -(view) | Author: Steve Dower (steve.dower)*![]() | Date: 2019-02-02 22:49 | |
So with the fix for multiprocessing, we currently rely on __PYVENV_LAUNCHER__ remaining set throughout the process.However, it may be better to add a "sys.base_executable" property instead and clear the __PYVENV_LAUNCHER__ variable once we've read it. Then we can set it again in multiprocessing and launch the base executable, and otherwise default to launching the redirector. | |||
| msg334813 -(view) | Author: Steve Dower (steve.dower)*![]() | Date: 2019-02-04 07:19 | |
New changeseta8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch 'master':bpo-35872 andbpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea67840779b9351f | |||
| msg334829 -(view) | Author: Steve Dower (steve.dower)*![]() | Date: 2019-02-04 15:20 | |
New changeset44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch '3.7':bpo-35872 andbpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4cfe8ddd67ed | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:10 | admin | set | github: 80054 |
| 2019-02-04 15:23:13 | steve.dower | set | keywords:patch,patch status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2019-02-04 15:20:38 | steve.dower | set | messages: +msg334829 |
| 2019-02-04 07:22:45 | steve.dower | set | pull_requests: +pull_request11692 |
| 2019-02-04 07:19:56 | steve.dower | set | messages: +msg334813 |
| 2019-02-03 00:01:07 | steve.dower | set | keywords: +patch stage: patch review pull_requests: +pull_request11671 |
| 2019-02-03 00:00:57 | steve.dower | set | keywords: +patch stage: (no value) pull_requests: +pull_request11670 |
| 2019-02-02 22:49:23 | steve.dower | set | messages: +msg334774 |
| 2019-02-01 09:03:04 | schlamar | create | |