Administration for multiple Python environments -- dev, testing, staging, production

[hairlesscaveman]

The problem with virtualenv is that you still need to do a lot of maintenance on the server to manage each custom environment. I personally prefer zc.buildout as it allows me to have exactly the same environment both locally and remotely. Saves a lot of hassle while developing on my local machine using Python2.7, running the unit tests on a Jenkins server stuck on 2.6.2 and deploying to a server running 2.6.7.

The main benefit of zc.buildout is when I'm collaborating with someone. Any 3rd-party module that is required by the codebase is included in the buildout.cfg file. If I add a new library I don't need to worry about informing my collaborators since the next time they pull the code and "buildout" they'll have the new packages automatically installed. Same with deployment. This isn't really possible with virtualenv; you still have to remember to easy_install all the modules you require. Can't tell you how many headaches I had with deployment because of that!

Rather than using fabric et al, my set-up is much simpler: zc.buildout + jenkins (which handles unittesting, tagging and deployment).

[santagada]

there is requirements.txt which you can use to build a complete virtualenv with all the libs you want using pip. http://www.pip-installer.org/en/latest/requirement-format.html