The more I've worked with installation and deployment and setuptools, the more I think site-packages (as in having /usr/lib/python2.4/site-packages on the path) is a bad idea, and that it should be empty and maybe not even on sys.path at all.

Why should anything get installed for the "site" aka "the computer"? The standard library gets that treatment, only only kind of, since there is actually a separate standard library for every major Python version, and those are kept carefully separate.

And the standard library is certainly not developed like nearly any other libraries that are used. It gets updated only with bugfixes until major releases, and even then with considerable consideration of backward compatibility. There are a few libraries that are similarly stable, like mx.DateTime, but not that many. (And in practice it is okay to put that kind of highly stable and infrequently-updated library in site-packages.)

For everything else site-packages is just a mess. What happens when you upgrade a library there? Who knows... maybe nothing (if there's another package earlier on the path that covers up the package in site-packages). Or maybe several packages will now need upgrades, as they depended on an interface that has now changed. Or maybe the system is just broken, because upgrades aren't available for everything that depended on the library.

And the whole thing is very implicit. Debugging import errors and sys.path is a pain in the butt. It leads to problems of software appearing to be fixed or upgraded or edited, when the actual code being loaded isn't what you intended. There are a lot of different things you can do with $PYTHONPATH, sitecustomize, .pth files, and other sys.path modifications. The order in which you do things can matter a lot. This all sucks.

Instead there should be a global installation of the standard library, plus those boring/stable libraries that can practically be considered "standard". And that's the only globally installed thing at all. Everything else is only installed in a specific context.

What is that context? I'm not exactly sure. I think all the pieces are in place to make the technical issues easy to resolve, and to make it easy to manage and work with localized contexts. But exactly how the user/developer works with these pieces, I'm not yet sure. But I am pretty sure that once we ditch site-packages completely -- get rid of the crufty old highly-coupled installations that regularly confound even the most experienced Python developers -- a whole lot of things surrounding installation will suddenly become a lot easier.