On 06/13/2011 08:07 AM, Nick Coghlan wrote: > On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip <vinay_sa...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com