[docs] [issue18939] Venv docs regarding original python install

[Graham Wideman]

Graham Wideman added the comment:

@Vinay Sajip  Thanks for looking at this issue and adding the link to PEP 405, and your explanation "When working..." with helpful shebang comments.

That said, the combination of PEP 405 and this updated page doesn't clear things up completely.

Vinay remarks "The venv documentation does assume that the reader knows what virtual environments are and how they work."

If so, let's have a link to where the reader can get up to speed on how they work. PEP 405 is a help, but doesn't detail the topics I raised in earlier thread messages. Also, different legacy virtual environment schemes work differently, so prior knowledge doesn't necessarily help.

But the article already has a link to "virtual environments"... to a box in the same article, which is at the heart of not bringing clarity to the topics at hand.

One problem is lack of clarity about what "active" and "activate" means. Here is what I currently believe:

In connection with venv, the term "active" is used in two relatively trivial but subtly different ways. 

(1) "First on PATH": The phrase "active environment" may be used to simply indicate the python environment which will be found first via the user's shell PATH. Further, each venv-configured python virtual environment installation includes an "activate" script whose main effect is just to add that environment's bin or Scripts directory to the beginning of the user's PATH. This makes the selected python environment the default when the user types the 'python' command. This use of "active" or "activate" might better be termed "default or "make default".

(2) "Actually running": A second meaning of "active" refers to an actually running instance of a python interpreter and its associated environment, whether or not it is first in the user's PATH. Any installed python (virtual or not) may be launched by explicitly invoking the complete path to its executable (eg: C:\python33\python.exe), whereupon that version of python will run, with its associated sys.path and so on.

These two meanings are obviously related. The particular python environment (virtual or not) that is "active" in the first sense, when invoked by a plain "python" command, will become "active" in the second sense.  But a running python ("active" in the second sense) will not necessarily be the "active" one in the first sense.

Implications for installers: A library installer invoked from the command line, unless told otherwise, will presumably install its payload into the python environment found via PATH. Consequently, in preparation, the intended target python should be made "active" in the first sense.

I have not elaborated here on my other concern (since I don't understand the details) -- clarification of different degrees of isolation/autonomy which can be established for each virtual environment. I still believe that's important to understand, and the current article and PEP 405 don't cover it successfully, in my view.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18939>
_______________________________________