The recent path discussion reminded me of a project I talked about with Larry Hastings at the last PyCon about virtualenv and what could possibly be included into Python.  Larry worked on a prototype that I was supposed to do something with, and then I didn't, which is lame of me but deserves some note:<br>

<br><a href="http://bitbucket.org/larry/pythonv/src">http://bitbucket.org/larry/pythonv/src</a><br clear="all"><br>It satisfies several requirements that I feel virtualenv accomplishes and a lot of other systems do not; but it also has a few useful features virtualenv doesn't have and is much simpler (mostly because it has a compiled component, and changes the system site.py).<br>

<br>The features I think are important:<br><br>* Works with "environments", which is a set of paths and installed components that work together (instead of just ad hoc single path extensions like adding one entry to PYTHONPATH)<br>

* Modifies sys.prefix, so all the existing installation tools respect the new environment<br>* Works with #!, which basically means it needs its own per-environment interpreter, as #! is so completely broken that it can't have any real arguments (though it occurs to me that a magic comment could work)<br>

* Doesn't use environmental variables (actually it uses them internally, but not in a way that is exposed to developers) -- for instance, hg should not be affected by whatever development you are doing just because it happens to be written in Python<br>

<br>Anyway, I think what Larry did with pythonv accomplishes a lot of these things, and probably some more constraints that I've forgotten about.  It does have a more complicated/dangerous installation procedure than virtualenv (but if it was part of Python proper that would be okay).<br>

<br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>