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. Unfortunately, there doesn't seem to be any real interest in standardising virtual environments at the moment. 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). I'd support a standardisation effort, but I don't intend to champion such an effort myself. 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). Paul _______________________________________________ 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/ITB4WDUWQD6KG7WPRJKTFAOG3TG5FQZS/ Code of Conduct: http://python.org/psf/codeofconduct/
