[Python-Dev] In-Python virtualisation and packaging

[Vinay Sajip]

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
virtualize.py.

> 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.)

Regards,

Vinay Sajip