➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2012-07-16 18:01 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.
| Messages (6) | |||
|---|---|---|---|
| msg165645 - (view) | Author: Antoine Pitrou (pitrou) *  |
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) * |
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) * |
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) * |
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) * |
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 |
| 2022-04-11 14:57:32 | admin | set | github: 59579 |
| 2012-07-17 08:57:51 | pitrou | set | status: open -> closed resolution: wont fix |
| 2012-07-17 08:09:24 | pitrou | set | messages: + msg165684 |
| 2012-07-17 03:23:20 | carljm | set | messages: + msg165674 |
| 2012-07-17 00:54:04 | vinay.sajip | set | nosy:
+ carljm messages: + msg165669 |
| 2012-07-17 00:15:58 | pitrou | set | messages: + msg165667 |
| 2012-07-16 23:59:32 | vinay.sajip | set | messages: + msg165666 |
| 2012-07-16 18:01:22 | pitrou | create | |