Paul Moore <p.f.mo...@gmail.com> added the comment:
On Thu, 27 Jun 2019 at 18:08, Steve Dower <rep...@bugs.python.org> wrote: > However, it does mean that we need to start reporting a sys.executable that > is not inside sys.prefix, and I'm not sure whether that is a good idea. > > Looking at venv (+Vinay for confirmation here), it seems to treat "home" as > "the directory containing the original Python binary" rather than "the > directory containing the Python install". So in theory (and in my simple > testing), using the sys.executable-not-in-prefix here is fine. But is that > intentional? I'm pretty sure there is code in the wild that expects <sys.prefix> / python.exe to be the Python executable (when you're not in a virtual environment). I seem to recall that virtualenv might do that sort of thing. Sorry I can't be precise here, I've just come back from holiday and won't be back into the swing of open source for a while yet, but my recollection is that it gets done in situations where sys.executable isn't (easily) accessible - for example, when getting sys.prefix from the registry (um, I don't think that's right, as the executable path is in the registry too - but you get the idea). What I'd say is that we should be cautious here, as we risk trading one breakage for another, rather than actually fixing the issue. Certainly the assumption I quote above is unwarranted, and code making it can't complain too much if it breaks, but the problem is that you *have* to make that assumption as the necessary information isn't available any other way. So we should do some careful testing of 3rd party tools like virtualenv, pipenv, pipx, pew, tox, etc, to make sure any "solution" here doesn't break them, and provide or document transition options for them if necessary (because such tools can't realistically avoid continuing to support older versions of Python). IMO, we should bite the bullet here and actually document the interfaces involved in virtual environments, so that tools have a stable contract to work with. That way we'd limit the need for people to rely on undocumented behaviour in the first place. Paul ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37369> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
