[Python-Dev] In-Python virtualisation and packaging (original) (raw)

Carl Meyer carl at oddbird.net
Tue Jun 14 01:46:33 CEST 2011

On 06/13/2011 08:07 AM, Nick Coghlan wrote:

On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip <vinaysajip 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

More information about the Python-Dev mailing list