Ian Bicking <i...@colorstudy.com> added the comment: This has a similar purpose to virtualenv, but using an environmental variable. An earlier package, workingenv, also used an environmental variable, and this led to a set of problems.
The biggest problem is that the environmental variable is inherited by subprocesses. This means if you install hg globally, then do subprocess.call(['hg', ...]), then hg will have picked up your local environment. Sometimes this is what you want (e.g., when using ipython) and sometimes not (probably not when using hg). Another problem is that scripts aren't really sticky with respect to the environment. When you install a script using this, it may only work when that same environmental variable is set. But the script remains present and callable regardless. Also, it's hard to mix and match environments in this system. These are real-world problems I encountered with workingenv, and virtualenv has resolved them very reliably by instead using sys.executable to select the environment. This requires some infrastructure in each environment which is unfortunate, but the result is more consistent behavior. ---------- nosy: +ianb _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5819> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com