One option I never see mentioned in any of these discussions about virtualenvs/stuff is my approach to python environments: Each project gets it's own VM/Contai

One option I never see mentioned in any of these discussions about virtualenvs/stuff is my approach to python environments: Each project gets it's own VM/Container. You then have one python version in the container, and no virtualenvs at all. All libraries get installed right into the main python libraries folder. I've been using this approach for 5+ years now, and I've yet to hit issues. I read people lamenting issues with python's packaging infrastructure, and with the approach I've never run into any of the issues they talk about. Pip complains a lot about being told to install stuff globally, but from what I can tell as long as you are careful enough to never use distro-sourced python packages (they're almost always out of date anyways, at least on ubuntu), it's never caused problems for me. For web-service type things, this has a lot of knock on effects that are beneficial. Each project winds up with it's own IP, if you need to restart things you can often just reboot the VM/container (assuming you have init scripts), process/library isolation issues are effectively impossible, etc...