[Python-Dev] In-Python virtualisation and packaging

[Carl Meyer]

On 06/13/2011 08:07 AM, Nick Coghlan wrote:
> On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> You're right in terms of the current Python ecosystem and 3.x adoption, because
>> of course this approach requires support from Python itself in terms of its
>> site.py code. However, virtual environments have a utility beyond supporting
>> older Pythons on newer OSes, since another common use case is having different
>> library environments sandboxed from each other on different projects, even if
>> all those projects are using Python 3.3+.
> 
> Yeah, even if the innate one struggles on later OS releases that
> changed things in a backwards incompatible way, it will still be
> valuable on the OS versions that are around at the time that version
> of Python gets released.

FWIW, historically pretty much every new Python version has broken
virtualenv, and new OS versions almost never have. Virtualenv isn't
especially OS-dependent (not nearly as much as some other stdlib
modules): the most OS-dependent piece is "shell activation", and that's
a feature I would prefer to entirely leave out of the stdlib virtualenv
(it's a convenience, not a necessity for virtualenv use, and the need to
maintain it for a variety of OS shells is a maintenance burden I don't
think Python should adopt).

In fact, the only new-OS-version adjustment I can recall virtualenv
needing to make is when Debian introduced dist-packages -- but even that
doesn't really apply, as that was distro-packager change to Python
itself. With a built-in virtualenv it would be the distro packagers
responsibility to make sure their patch to Python doesn't break the
virtualenv module.

So I don't think a virtualenv stdlib module would be at all likely to
break on a new OS release, if Python itself is not broken by that OS
release. (It certainly wouldn't be the stdlib module most likely to be
broken by OS changes, in comparison to e.g. shutil, threading...)

Carl