[Python-Dev] In-Python virtualisation and packaging

Vinay Sajip vinay_sajip at yahoo.co.uk
Mon Jun 13 14:22:32 CEST 2011

Michael Foord <fuzzyman <at> voidspace.org.uk> writes:

> It would certainly need a PEP.

Of course.

> There are two options:
> Bring the full functionality into the standard library so that Python 
> supports virtual environments out of the box. As is the case with adding 
> anything to the standard library it will then be impossible to add 
> features to the virtualization support in Python 3.3 once 3.3 is 
> released - new features will go into 3.4.
> Add only the minimal changes required to support a third-party virtual 
> environment tool.

Agreed. As I see it, the "minimal changes required" are everything in my fork
except for "virtualize.py", which was actually written as an external module
"pmv.py" - Poor Man's Virtualenv ;-)

Having it as a minimal implementation in the stdlib accords with "batteries
included", but even as it stands, virtualize.py does try to cater for
customisation. Firstly, there's a virtualizer_factory callable which can be
overridden for customisation. That's called to produce a virtualizer, whose
virtualize method is called with the target directory. The virtualize()
function in virtualize.py just does this set of steps. I can't claim to have
thought of everything, but it's a simple API which could have any number of
implementations, not just the default one in the Virtualizer class in

> Don't forget windows support! 

I haven't. Though I haven't tested the most recent changes on Windows yet, I
have tested the basic approach under Windows (the code doesn't rely on
symlinks, but rather, copies of executables/DLLs). (All Windows testing so far
has admittedly been using source builds rather than via a binary installer.)


Vinay Sajip

More information about the Python-Dev mailing list