Everything boils down to whether you'd like to run more than one app on your box.
> While I love pip and virtualenv in development, I don't understand the > advantage they offer over the system package manager on a production > machine. Easy: whenever you can't be bothered with proper containers. App X requires package foo version 1.2, app Y requires foo version 1.4. Docker solves this universally. You can also achieve a similar effect by building a chroot. virtualenv's advantage is it doesn't require root, and is (subjectively) easier to use. Also dev = staging = live. Every difference between the environments is a potential bug, ready to blow up in your face the moment you hit the deploy button. > In addition, I feel that a reasonable uwsgi package would include an > rc-script to start your app automatically at system boot time. I prefer to run my application servers with runit. Traditional RC scripts usually assume one package = one application instance. Usually that's a sane assumption (what would be your reason for running two instances of Apache?) but again, if you can't be bothered with containers, virtualenv+runit make it easy to just put app X in /home/x, app Y in /home/y, then run two uwsgi's. > There's no doubt that all of this could be hand hacked but the way I > see it the less hand hacking on production machines, the better. It > might just be my style, but I feel that the less work I have to do on > a production system from the command line, the more reliable that > system will be. You've mentioned Puppet. Also check out Ansible. K.
