On Jun 21, 2012, at 08:51 AM, Chris McDonough wrote:
The reason it's disappointing to see OS vendors mutating the default sys.path is because they put *very old versions of very common non-stdlib packages* (e.g. zope.interface, lxml) on sys.path by default. The path is tainted out of the box for anyone who wants to use the system Python for development of newer software. So at some point they invariably punt to virtualenv or a virtualenv-like system where the OS-vendor-provided path is not present.
If Python supported the installation of multiple versions of the same module and versioned imports, both PYTHONPATH and virtualenv would be much less important. But given lack of enthusiasm for that, I don't think it's reasonable to assume there is only one sys.path on every system.
This is really the key insight that should be driving us IMO. From the system vendor point of view, my job is to ensure the *system* works right, and that everything written in Python that provides system functionality is compatible with whatever versions of third party Python packages I provide in a particular OS version. That's already a hard enough problem, that frankly any illusions that I can also provide useful versions for higher level applications that people will deploy on my OS is just madness. This is why I get lots of people requesting versioned imports, or simply resorting to venv/buildout/chef/puppet/juju to deploy *their* applications on the OS. There's just no other sane way to do it. I do think Python could do better, but obviously it's a difficult problem. I suspect that having venv support out of the box in 3.3 will go a long way to solving some class of these problems. I don't know if that will be the *only* answer. -Barry