Having a global python installation where packages are constantly installed, uninstalled, and updated is the path to madness. If something goes wrong, what can you do? You can't wipe out the system python. You can wipe out a virtualenv though.

What do you mean by goes wrong? Either some package is installed or not. For me, chef manages which ones are. If something is really FUBAR, then wiping is exactly the path I'd take - or more accurately, take that server down for analysis of how exactly it got into that state (so we won't do that again) and bring a clean one up.

Mainly it's about incompatibilities. What if you have two apps that require different versions of a library? If you've installed it in site-packages, then you have little recourse. By separating them out with virtualenv the two apps will work just fine.

Fortunately I'm in a one-service-one-server environment, so I may be biased here ;)

Well, not really, because what if ubuntu packages rely on version X, and you need version Y.

You roll version Y yourself and install it into an alternate prefix. If the server uses debian that means make a new deb and deploy it using the standard tools. apt-get/yum/etc. are very solid deployment tools.

I wasn't saying it was impossible, but what you've described is already about 10 times harder than using virtualenv.

> what can you do?

Understand what went wrong and not ignorantly hit Ctrl-Alt-Delete.

What is the benefit of using global packages? If you pin them, what do you gain? virtualenv give you complete control over the runtime environment of every single application. Stuff like what you wrote can’t really happen.

And BTW, there’s more stuff that can happen than breaking APIs: new bugs that happen only on your system or even better: your code worked only _because_ of a bug. :)

For me the benefit is a much easier security audit/update. Unless you have dependencies packaged by yourself, the only thing you need to monitor is what comes into security-updates of your repository. If there's anything new, do a test deployment, do what you do to verify it's correct and change the pin in production.

Honestly: how many people installing software through virtualenv are registered to security mailing lists for each of their packages (and their dependencies down to things like simplejson)?

But if you _pin_ your packages, how are you updating? You have to monitor it anyway.

High profile projects like simplejson, Django or Pyramid and their deps won’t be missed and the really obscure ones will never make it into the repositories anyway.

Of course. I'm just saying that in case you're pinning only the default upstream versions from your distro so that they don't change, it's easier to automatically report on which packages have a new version in {distro}-security repository. Then retest and change the pin.

The same can be achieved by subscribing to CVEs... but you have to remember to filter the ones you use. Of course that's not a huge difference, so if someone prefers the second way, there's nothing wrong with it ;)

Your system python applications might have different requirements to your project. Just use virtualenv, it's easier and less error-prone.

You never have two apps deployed on the same server that need different versions of a dependency?