[Python-Dev] Status of packaging in 3.3

[Barry Warsaw]

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