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