On Wed, Mar 25, 2020 at 9:57 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> On Wed, 25 Mar 2020 at 16:10, Eryk Sun <eryk...@gmail.com> wrote: > > > The py launcher's "env" command searches PATH for anything from > > "python" to "notepad" -- but not for a versioned Python command such > > as "python3" or "python2". It always uses a registered installation > > in this case, which is at the very least problematic when using > > "#!/usr/bin/env python3" in an active virtual environment. Paul Moore > > will probably suggest that the script should use "#!/usr/bin/env > > python" instead, > > Nope, I agree with your point about that running 2.x on Unix. > > IMO, the /usr/bin/python* and /usr/bin/env aliases are for Unix > compatibility and so should prioritise that - but because Windows > python doesn't include versioned executables, it's not always easy to > do that. > > > but that will run 2.x in most Unix systems unless a > > 3.x environment is active. We can assume that such a script requires > > 3.x and is meant to run flexibly, in or out of an active environment. > > In principle I agree, but I'm not sure how you see that working in > practice. If you have an activated venv, `#!/usr/bin/env python3` > should use the venv Python or the system Python depending on whether > the venv is Python 3 or not. But the only way of finding that out in > the absence of versioned executables is running `python -V`. That's a > performance hit that I'd rather we avoided. > > [see below about pyvenv.cfg - tl;dr is that there's no *documented* > version info in there] > > > I'd prefer a consistent implementation of the "env" command that > > doesn't special case versioned "pythonX[.Y]" commands compared to > > plain "python". But another option that will at least make > > virtual-environment users happy would be for "env" to check for an > > active VIRTUAL_ENV and read its Python version from "pyvenv.cfg". > > I'd agree with that, if we had versioned executables. Without them, I > honestly don't know what answer would cause the fewest issues, so I > tend to assume that sticking with what we have is good enough, because > we're not getting lots of complaints (we get some, but not that many). > > Following on from my comment above about needing to run `python -V`, > I'd completely forgotten that pyvenv.cfg held the version statically > nowadays. > > But virtualenv 20.0 and later writes a pyvenv.cfg with different > information, and virtualenv < 20.0 doesn't write pyvenv.cfg at all. > I'm OK with discounting old versions of virtualenv, but realistically, > I believe that not interoperating with current versions of virtualenv > is impractical. I think that if we want to rely on pyvenv.cfg, we > should document/standardise its contents. At the moment, the docs only > mention `home` and `include-system-site-packages`, and to be honest > they sound more informational than normative anyway. > 3.9 adds "prompt" to record any custom prompt that was specified. > > Unfortunately, there doesn't seem to be any real interest in > standardising virtual environments at the moment. I have interest. :) > So for now, at > least, it's difficult to see how the launcher can behave as you want > (I assume it's obvious that we don't want to hard-code implementation > details of virtualenv into the launcher). Up to this point the only thing the Launcher has is support for when the VIRTUAL_ENV environment variable is defined (my hope to standardize on environment naming seems to have stalled out). > I'd support a > standardisation effort, but I don't intend to champion such an effort > myself. > I don't either ATM, but maybe someday. > > Just to reiterate, I'd like a better, more uniform solution here. But > I think there's more complexity than people are assuming, at least if > we want to interoperate with 3rd party tools (which I view as > necessary, although I guess others may take a more hard-line stance). >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6YFTKDP7AAEIOKNSR2F6TK64XS57VKV4/ Code of Conduct: http://python.org/psf/codeofconduct/
