[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: > "__pypackages__" doesn't seem like a drop-in replacement for virtual > environments. Right, it's not. But if enough people adapt their workflows to use [something like] it rather than relying on having a local copy of python.exe in order to launch, apps that

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > "C:\Program Files\WindowsApps\venvlauncher.exe" The above was supposed to be "C:\Program Files\WindowsApps\Python...\venvlauncher.exe", where "Python..." is the elided name of the package directory. -- ___ Python

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > the Store package, which can only be *executed* from outside its > container (we can't load the DLL directly). The idea I was pondering was to create "python.exe" in the virtual environment as an appexec link to "C:\Program Files\WindowsApps\venvlauncher.exe"

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: The main motivator for the redirector was to support the Store package, which can only be *executed* from outside its container (we can't load the DLL directly). Given we want the two distributions to be interchangeable from a code POV, it made the most sense

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: In some cases, the problem can be worked around by setting the __PYVENV_LAUNCHER__ environment variable and executing the base executable. For example: import os import sys import subprocess def get_python_exe_env(): if sys.executable ==

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Assaf added the comment: The fact that now there is a redirector process seems to me like a regression issue. I have an application which Popen several processes and uses the Popen object in order to get the subprocesses pids and act upon this pids (i.e. looks for log files with associated

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Alexander Stepanov added the comment: Another victim of this change in `venv` behavior is Ray, which hangs forever because the workers fail to register as parent does not recognize their PIDs. https://github.com/ray-project/ray/issues/13794 -- nosy: +nirvana-msu

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Sergey Nudnou added the comment: Hello, I've just run into a related issue. I have a python script, which starts an another python script using subprocess.Popen(). The parent script gets pid of the child and monitors up its activity through a database by this pid. The child script updates

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: Thanks for confirming that reality aligns with the documentation. > when doing the same and passing `shell=True` to the POpen() call, there is no > such initial folder in the lookup Correct, because a fully qualified path to cmd.exe is used, and cmd.exe's

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Jurko Gospodnetić added the comment: encountered what I believe is the same problem, so here are some more details I noticed, after checking what exactly that process name lookup does using ProcessMonitor: - when running my external process in a `venv` generated virtual environment, POpen()

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: I posted a workaround right above your post for when you want to resolve executables against PATH instead of using Windows's normal rules. I'm not sure we reached any good approach for launching sys.executable in a venv and automatically bypassing the

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Benedek Rácz added the comment: Is there any update/solution for this issue? This issue is the root cause of this SO post: https://stackoverflow.com/q/61290972/2506522 -- nosy: +Benedek Rácz ___ Python tracker

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: > But then I need two separate workflows based on what is passed in. For py.exe > I need to run it and get sys.executable. But for python.exe I *cannot* use > sys.executable because that’s the base interepeter, not the venv path I want. > And `if Path(arg).stem

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: >> not enough since it’d break `flit install --python=py` because that’s give >> you the location of py.exe, not the actual interperter. > This would be fine if you still run the process to get its sys.executable. But then I need two separate workflows based

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: > Perhaps generalize this as splitext(basename(sys.executable))[0] in > order to support names other than "python" and "pythonw". It would have > to handle quoting enough to ignore an initial double quote when parsing > the executable name out of an args string,

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > Possibly we could handle "python[.exe]" literals by substituting > sys.executable transparently? Perhaps generalize this as splitext(basename(sys.executable))[0] in order to support names other than "python" and "pythonw". It would have to handle quoting

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: > `shutil.which` could be a direction, but still not enough since it’d break > `flit install --python=py` because that’s give you the location of py.exe, > not the actual interperter. This would be fine if you still run the process to get its sys.executable.

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: To provide concrete context, the problem I’m facing is with how Flit resolves `flit install --python`: https://github.com/takluyver/flit/blob/7e65ffc7a540d76b96de0df473d3edff6f97c26c/flit/__init__.py#L18-L28 Generally the setup is to install Flit into a

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Steve Dower added the comment: Yeah, this definitely relates to how Windows handles unqualified argv[0] in CreateProcess. Though I thought we checked that out in another issue and decided that "most" people are correctly using sys.executable here? (Or decided that it was documented well

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > "running an unqualified python and expecting a PATH search to pick up > the same executable as the parent shell would is not supported and may > produce unexpected results" CreateProcessW finds "python.exe" in __APPDIR__ before it even searches PATH. I expect

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Paul Moore added the comment: I presume there's also the option of setting up the environment (or however it's done now - I know the details changed as the feature was developed) so that the "base" python.exe pretends to be the venv one, exactly as the wrapper does. However, that may well

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > whens searching for executables, Windows gives "exes that are in the > same directory as the currently executing code" priority over PATH. That subprocess lets CreateProcessW use a platform-dependent search that prioritizes the application directory has come up

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Paul Moore added the comment: Yes, it does. I think we'd need input from Steve Dower here, as these changes were made (I believe) in support of the Windows Store build of Python, so any changes would need to be considered in the light of how they would affect that. I do, however, consider

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: I tested the following in various versions (all 64-bit) in a VM. All installations are 64-bit per-user. > py -m venv testenv > testenv\Scripts\python.exe -c "import subprocess; > print(subprocess.check_output(['python', '-c', 'import sys; >

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Paul Moore added the comment: The behaviour in this area is different between 3.7.0, 3.7.2, and 3.7.3 (at least). I have reproduced the issue with 3.7.3. Steve Dower made changes to the way the python executable works in venvs in the point releases of 3.7 - see

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: > If you don't use activate.bat, but just run the venv's python directly, what > do you see? I get: > What shell are you using? Above is with cmd.exe. I get the same result as activating (i.e. shows the base interpeter). All results in cmd.exe as well. > If

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eric V. Smith added the comment: Your failing test case with 3.7 works for me. If you don't use activate.bat, but just run the venv's python directly, what do you see? I get: >py -m venv fooenv >fooenv\Scripts\python -V Python 3.7.0 >fooenv\Scripts\python -q >>> import subprocess >>>

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Change by Karthikeyan Singaravelan : -- nosy: +eryksun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: 3.6 works correctly on Windows: > py -3.6 -m venv test36 > test36\Scripts\activate.bat >>> import subprocess >>> print(subprocess.check_output(['python', '-c', 'import sys; >>> print(sys.executable)']))

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: Linux works correctly (Ubuntu with self-compiled Python 3.7.5) $ python3.7 -m venv fooenv $ . fooenv/bin/activate (fooenv) $ python -c "import sys; print(sys.executable)" /home/uranusjr/fooenv/bin/python (fooenv) $ python -q >>> import subprocess >>>

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

New submission from Tzu-ping Chung : To reproduce: > py -m venv fooenv > fooenv\Scripts\activate.bat (fooenv) > python -c "import sys; print(sys.executable)" % This is correct C:\Users\uranusjr\Downloads\venvtest\Scripts\python.exe (fooenv) > python -q >>> import subprocess >>>