[Python-Dev] Status of the built-in virtualenv functionality in 3.3

Barry Warsaw barry at python.org
Thu Oct 6 18:02:05 CEST 2011


On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:

>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
>> that picking something cute might make it harder to discover.  `pythonv` or
>> `cpythonv` seem like good choices to me.  Maybe the former, so we could
>> potentially have jythonv, etc.
>
>I’m not sure we would.  The feature is two-fold:
>- changes to getpath.c, site.py and other usual suspects so that CPython
>supports being run in an isolated environment;
>- a new module used to create isolated environments.

While the other implementations might not be able to share any of CPython's
code, it's still a worthy feature for any Python implementation I think.

>The first part is implemented in CPython; the second part needs a module
>name to replace virtualenv.  python -m pythonv doesn’t seem right.

Nope, although `python -m virtualize` seems about perfect.

I don't particularly like the -m interface though.  Yes, it should work, but I
also think there should be a command that basically wraps whatever the -m
invocation is, just for user friendliness.

>python -m makeenv?
>python -m workon? (idea from virtualenvwrapper)
>python -m nest?

Well, I have to be honest, I've *always* thought "nest" would be a good choice
for a feature like this, but years ago (IIRC) PJE wanted to reserve that term
for something else, which I'm not sure ever happened.

There's a PyNEST project here:

http://www.nest-initiative.uni-freiburg.de/index.php/PyNEST

which might cause problems with a built-in `nest` module.  Still, I'm a bit
fond of `python -m nest` and a `pynest` wrapper.

Barring that, `python -m virtualize` with an appropriate cli shortcut
(`pysolate`? - say it out loud :) seems good.

-Barry


More information about the Python-Dev mailing list