Message347374
On Thu, 27 Jun 2019 at 18:08, Steve Dower <report@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 |
|
Date |
User |
Action |
Args |
2019-07-05 20:10:39 | paul.moore | set | recipients:
+ paul.moore, vinay.sajip, vstinner, tim.golden, ned.deily, zach.ware, eryksun, steve.dower, bstorm |
2019-07-05 20:10:39 | paul.moore | link | issue37369 messages |
2019-07-05 20:10:39 | paul.moore | create | |
|