Fabric isn't normally deployed on target servers though - it connects to them through SSH.

That’s not what I meant: If you build your virtualenv on the target server, you need build tools like GCC or development files like libpq-dev. I prefer to have as few stuff on servers as possible.

Thanks - that does sound like a big advantage of the deb / rpm route. Plus you don't really want your app servers spending their CPU time compiling.

That’s a plus too. An “aptitude dist-upgrade” is really fast.

Yes, but unless rpm/deb works with softlinks, it is not atomic right? Do you do anything before/after dist-upgrade or is it included in the pre/post install script?

For example, for our deployment, we rely on softlinks and uwsgi robust reload behavior to avoid losing requests. I've seen many devops who were using hg update/git update as a way to "deploy" (arg!), but I'm not sure about the behavior of deb/rpm.

You can do whatever you want inside of the post-install hooks which are just shell scripts. Including any kind of soft link black magic. :)

And you’re right: replacing files of a running application can lead to all kind of weirdness. I’d even prefer to lose some requests than to risk that.

DEBs for your own project files, or debs containing built python modules that the server needs to run those project files?

If the latter, how well does that mix in with virtualenv? or do you just avoid it entirely?

I’m the dude that wrote article, so like it says: Own stuff + deps.

Your can re-initialize a virtualenv to fix it by simply running virtualenv again.

But pinky swear I’ll write the second article. ;)

Get on it! :) I really enjoyed the article and want to know more of your magic.