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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com