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 <rep...@bugs.python.org>
<http://bugs.python.org/issue18939>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
