Eryk Sun <[email protected]> added the comment:
> But if I understood what Steve said, only if path\to\python.exe is
> a *relative* pathname?
I believe Steve is referring to behavior changes for applications that relied
on a virtual environment's "Scripts" directory always being in the EXE and
default DLL and generic search paths because it was the application directory
(i.e. "%__APPDIR__%"), which I had discussed in a follow-up note. I suggested
that this could be mitigated by having the new venv launchers also prepend
their directory to PATH. It wouldn't help in all cases, but it's the best we
can do.
The issue with __PYVENV_LAUNCHER__ and the py.exe and entry-point launchers is
unrelated to relative paths. Perhaps it will clarify the situation to show how
this variable is actually used in PC/getpathp.c. It's a pretty simple change:
/* The launcher may need to force the executable path to a
* different environment, so override it here. */
pyvenv_launcher = _wgetenv(L"__PYVENV_LAUNCHER__");
if (pyvenv_launcher && pyvenv_launcher[0]) {
wcscpy_s(program_full_path, MAXPATHLEN+1, pyvenv_launcher);
} else if (!GetModuleFileNameW(NULL, program_full_path, MAXPATHLEN)) {
/* GetModuleFileName should never fail when passed NULL */
return _Py_INIT_ERR("Cannot determine program path");
}
https://github.com/python/cpython/blob/v3.7.2/PC/getpathp.c#L535
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue35811>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
