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.