The pain (or annoyance) of deploying a simple WSGI thing
It started on Twitter:
@eevee: it is time once again to set up a small innocuous wsgi thing and i am again reminded that this sucks and i want to fix it so bad
@thatcks: If only deploying a WSGI thing was as easy as PHP. And I wish I was making a joke there.
Some number of people are now thinking that there's no problem here and that WSGI apps are pretty easy to deploy. After all there's lots of WSGI servers, many of them quite good, and it's not like it's hard to hook one up to your main (or frontend) web server. An entry here, an entry there, a new daemon process, and you're done. Maybe you even use Apache's mod_wsgi, which gets it down to a configuration entry (and a server restart, but you probably needed that anyways).
Well, here's the simple PHP deployment process: put a
.php file in
the appropriate spot in your web server's document root. You're done.
(As noted by @bobpoekert, CGIs also have basically this property.)
Yes, yes, of course there is a great pile of stuff behind the scenes to
make that work. And of course it isn't as flexible and as scalable as
the full bore WSGI version. But it demonstrates what a simple deployment
actually is and frankly a simple basic deployment is all that 99% of all
web apps need (the existence proof is all of the basic PHP apps). Even a
relatively full-featured WSGI deployment should only require two files
and nothing else (one actual
.wsgi file and one file to describe
things like what URL it connects to), with the pieces to make it work
integrated with your web server.
(The actual running of your WSGI app could be in a separate container daemon that's handled by a separate supervision process. That's an implementation detail that you shouldn't have to care about for a simple WSGI deploy process any more than you should have to care about the details of how your web server communicates with your WSGI app.)
As a side note, as a sysadmin I happen to think that standalone daemons are both a pain in the rear and utterly the wrong approach for a scalable deployment of lots of apps with unpredictable load. But that's another blog entry.