> On 25 Mar 2020, at 16:53, 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.
At least on Fedora python is python3 now.
On Centos 8 there is no python until you use the alternatives mechanism
to set it as python2 or python3.
Barry
>
> 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/
>
_______________________________________________
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/BP3TSQBIKVM23KBKKOT7NASZLDWNVIHP/
Code of Conduct: http://python.org/psf/codeofconduct/
