New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EnvBuilder and venv symlinks do not work on Windows on 3.7.2 #80035
Comments
The change to pull the redirector executables as part of scripts was... perhaps too clever. There exists code out there that uses EnvBuilder to create environments _without_ copying scripts, which now results in an environment that does not include python.exe. It also undid symlink support, as scripts are never symlinked. I'll restore both. |
Actually, it seems like venv symlinks are so far from working that they haven't worked (on Windows) since 3.5 or possibly earlier. I'm just going to make that option ignored and mark it as such in the docs. |
I use venv with --symlinks prior to 3.7.2. It works fine as far as I can tell. Perhaps you could elaborate. I assumed you removed it because it's not compatible with the Microsoft Store release for some reason. The loader doesn't resolve links, so it should work as long as the python.exe, python3x.dll, python3.dll, and vcruntime140.dll files are linked together in the Scripts directory. >>> hPython3 = ctypes.WinDLL('python3')._handle
>>> hVcruntime140 = ctypes.WinDLL('vcruntime140')._handle
>>> for h in (0, sys.dllhandle, hPython3, hVcruntime140):
... print(_winapi.GetModuleFileName(h), '->')
... print('\t', os.readlink(_winapi.GetModuleFileName(h)))
...
C:\Temp\env36\scripts\python.exe ->
C:\Program Files\Python36\python.exe
C:\Temp\env36\scripts\python36.dll ->
C:\Program Files\Python36\python36.dll
C:\Temp\env36\scripts\python3.dll ->
C:\Program Files\Python36\python3.dll
C:\Temp\env36\scripts\VCRUNTIME140.dll ->
C:\Program Files\Python36\vcruntime140.dll
>>> print(sys.executable)
C:\Temp\env36\scripts\python.exe
|
No, removing it was accidental. But when I tried it myself with a few regular installs of 3.5 and later, none of them updated sys.path correctly, and all of them resolved the links in the loader (or perhaps the shell?). I hadn't activated the environments, as I generally don't, but if that's required for symlinks to work here then I consider them broken. |
Okay, testing more thoroughly on 3.5, symlinks are fine from the console but not via Explorer. Personally, I dislike that double-clicking python.exe is different from running it from the command line, but so be it. I'll add a note to the docs that this doesn't work. |
I gave up on using EXE symlinks with Explorer and ShellExecute[Ex]. The shell handles symlinks like shortcuts instead of leaving it up to the file system. In Windows 7, I recall it was thoroughly broken. Symlinks wouldn't even execute. In Windows 10 it's broken in many cases because of the shortcut-like behavior. I think I know why they're doing this, but I think the fix belongs at a lower level in the system runtime library and loader. It's to accommodate the importance of the application directory. People expect a symlink to an executable to work like a shortcut. In Unix this often just works because most libraries are installed to the system, and an application's private shared libraries can use "$ORIGIN" in the binary's RPATH (or RUNPATH), which refers to the resolved (final) executable directory. In contrast, Windows doesn't use the resolved executable path for the application directory. IMO, they could use a pair of application directories at the start of the search path -- the link's directory and then the resolved executable's directory (or the DLL directory when loading a DLL). Some resources do get resolved like this already. For example, when searching for a "<local name>\<exename>.mui" language resource, in Process Monitor we see that it will first try the unresolved application directory (e.g. "C:\Temp\en-US\notepad.exe.mui") and then the resolved path (e.g. "C:\Windows\en-US\notepad.exe.mui"). |
Can we close this issue now? |
Yep. Done |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: