== The pain (or annoyance) of deploying a simple WSGI thing

It started on Twitter:
> [[@eevee
> https://twitter.com/eevee/status/379790467732221953]]:
> 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
> https://twitter.com/thatcks/status/379803759100317697]]:
> If only deploying a WSGI thing was as easy as PHP. And I wish I was
> making a joke there.

(Note that [[@eevee https://twitter.com/eevee/]] is the author of
the infamous rant [[PHP: a fractal of bad design
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/]].)

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
https://twitter.com/bobpoekert/status/379792080337260544]], 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.