On Wed, 25 Mar 2020 at 16:10, Eryk Sun <firstname.lastname@example.org> 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
> 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
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
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).