[Python-Dev] Status of the built-in virtualenv functionality in 3.3 (original) (raw)

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