classification
Title: venv environment variable should follow the conventions
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: carljm, georg.brandl, pitrou, vinay.sajip
Priority: deferred blocker Keywords:

Created on 2012-07-16 18:01 by pitrou, last changed 2012-07-17 08:57 by pitrou. This issue is now closed.

Messages (6)
msg165645 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-16 18:01
pyvenv's environment variable is currently named VIRTUAL_ENV (it seems).
It would be better if it followed the trend of other Python environment variables such as PYTHONHOME, PYTHONSTARTUP, etc.
(so, PYTHONVENV ?)

Setting as deferred blocker, since it would be better for existing venvs not to be made useless.
msg165666 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-07-16 23:59
This name was picked because the virtualenv tool uses it, and keeping the name allows any existing third-party projects and scripts which use it to require minimal, if any, changes.
msg165667 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-17 00:15
> This name was picked because the virtualenv tool uses it, and keeping
> the name allows any existing third-party projects and scripts which
> use it to require minimal, if any, changes.

Which means that these third-party projects are automatically compatible
with pyvenv?
msg165669 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-07-17 00:54
> Which means that these third-party projects are automatically
> compatible with pyvenv?

I can't speak for them, but it's one less thing for people to have to change. The intention certainly was to minimise friction in this area.

I would be interested in Carl's opinion (as he's a virtualenv maintainer).
msg165674 - (view) Author: Carl Meyer (carljm) * Date: 2012-07-17 03:23
Yes, there are a number of third-party utility packages (and many, many e.g. personal custom bash prompts) that check the value of the $VIRTUAL_ENV variable to detect whether one is currently active, and display its name. Unless there's an overriding reason, it would be nice to not require changing all of this code.

Certainly not all third-party virtualenv-related tools will be compatible with pyvenv unchanged; for instance tools that create envs will need to use the updated pyvenv API. But there is a lot of code using $VIRTUAL_ENV that won't require any other changes, if we can keep using the same env var.
msg165684 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-17 08:09
> Yes, there are a number of third-party utility packages (and many,
> many e.g. personal custom bash prompts) that check the value of the
> $VIRTUAL_ENV variable to detect whether one is currently active, and
> display its name. Unless there's an overriding reason, it would be
> nice to not require changing all of this code.

Ok, it sounds reasonable enough.
History
Date User Action Args
2012-07-17 08:57:51pitrousetstatus: open -> closed
resolution: wont fix
2012-07-17 08:09:24pitrousetmessages: + msg165684
2012-07-17 03:23:20carljmsetmessages: + msg165674
2012-07-17 00:54:04vinay.sajipsetnosy: + carljm
messages: + msg165669
2012-07-17 00:15:58pitrousetmessages: + msg165667
2012-07-16 23:59:32vinay.sajipsetmessages: + msg165666
2012-07-16 18:01:22pitroucreate