classification
Title: venv does not include python. symlink by default
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: eric.araujo, eryksun, lys.nikolaou, vinay.sajip
Priority: normal Keywords:

Created on 2020-02-14 14:06 by lys.nikolaou, last changed 2020-02-16 14:44 by eryksun. This issue is now closed.

Messages (8)
msg361993 - (view) Author: Lysandros Nikolaou (lys.nikolaou) * (Python committer) Date: 2020-02-14 14:06
At the moment running python -m venv venv or python3 -m venv venv creates a virtual environment that does not contain a python<major>.<minor> symlink, which results in executing whatever the default python is when running i.e. python<major>.<minor> within an activated virtual env. OTOH if one runs python<major>.<minor> -m venv venv, then everything is OK. Would it be possible to include a python<major>.<minor> symlink in all cases? If not, then I think we should update the docs to mention that somewhere, since it took me quite a while to figure this out.
msg362002 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2020-02-14 22:14
When a venv is activated, only one Python interpreter is active - whichever one the venv was created with. Why would you want to invoke it with `pythonX.Y` when `python` would do? I don't think that this is something people generally do - this has never come up before AFAIK. What if you invoked it with the wrong values of X.Y?
msg362004 - (view) Author: Lysandros Nikolaou (lys.nikolaou) * (Python committer) Date: 2020-02-15 02:24
The thing is that some projects I've worked on, like pegen, include a Makefile which uses `pythonX.Y` to choose the version and I have to change it to `python` quite frequently. 

I can't really figure out any way this could harm anyone, other than what you said (running `pythonX.Y` with the wrong values for X and Y), but even in that case you get something like `command not fonund` and that's an easy enough typo to find.
msg362021 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2020-02-15 17:18
Except that if there's a global other pythonX.Y of the different version, that would get run ... potentially even more confusing.
msg362024 - (view) Author: Lysandros Nikolaou (lys.nikolaou) * (Python committer) Date: 2020-02-15 17:52
You're right! That could be very confusing. But isn't this risk already there, since this could happen if one runs `python3.8 -m venv venv` and then `python3.7` with the venv activated?
msg362032 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2020-02-15 21:32
In general, people should be working in venvs. That means that libraries should assume they are being installed into venvs. Therefore makefiles should be invoking plain "python" rather than "pythonX.Y", as they can never be sure which exact interpreter they're running under (you might have a newer one than the one in the Makefile - that shouldn't fail). Why not raise this as an issue with these projects?
msg362035 - (view) Author: Lysandros Nikolaou (lys.nikolaou) * (Python committer) Date: 2020-02-15 21:38
That's right. I'll do that then. Thanks for baring with me.

Should we update the docs to mentiom this or just close this issue?

On Sat, Feb 15, 2020, 22:33 Vinay Sajip <report@bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip@yahoo.co.uk> added the comment:
>
> In general, people should be working in venvs. That means that libraries
> should assume they are being installed into venvs. Therefore makefiles
> should be invoking plain "python" rather than "pythonX.Y", as they can
> never be sure which exact interpreter they're running under (you might have
> a newer one than the one in the Makefile - that shouldn't fail). Why not
> raise this as an issue with these projects?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue39633>
> _______________________________________
>
msg362075 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2020-02-16 14:44
> That means that libraries should assume they are being installed into
> venvs. Therefore makefiles should be invoking plain "python" rather
> than "pythonX.Y"

In Unix, 3.x virtual environments include a "python3" symlink or copy, even if created with a "python" command. A makefile that needs Python 3 can rely on running "python3" -- but only in Unix. Though someone using Unix tools in Windows (not Cygwin or MSYS2) must already be prepared for this.
History
Date User Action Args
2020-02-16 14:44:48eryksunsetnosy: + eryksun
messages: + msg362075
2020-02-16 08:52:53vinay.sajipsetstatus: open -> closed
type: behavior
resolution: not a bug
stage: resolved
2020-02-15 21:38:47lys.nikolaousetmessages: + msg362035
2020-02-15 21:32:53vinay.sajipsetmessages: + msg362032
2020-02-15 17:52:59lys.nikolaousetmessages: + msg362024
2020-02-15 17:18:48vinay.sajipsetmessages: + msg362021
2020-02-15 02:24:08lys.nikolaousetmessages: + msg362004
2020-02-14 22:14:57vinay.sajipsetmessages: + msg362002
2020-02-14 18:41:01eric.araujosetnosy: + vinay.sajip, eric.araujo
2020-02-14 14:06:58lys.nikolaoucreate