It was almost midnight, and my fellow hackers were starting to vacate my living room. My little project was getting to a point where I could have people play with it (but not enough to say "fini"). I made a few small changes, and then called fab deploy (because I heart fabric) and the deployment was complete. I went to the public site, futzed around, and was bummed to find that the view that was really the bread and butter of the site wasn't working. It would never return a response. As the participants in my hack night left, I continued debugging, not sure what was going on.
At about 1:30, I went to bed, confident that the answer would find me in the morning when I was rested.
The answer must have gotten stuck in traffic, for when I arose the next morning, it had not yet arrived. I had a few ideas what the problem would be, since this specific Django "view" made some calls to the command line and parsed the output. I did some things with apache and gdb that I'm not proud of (things that I still don't quite understand), and found the answer:
mod_wsgi blocks access to sys.STDIN and sys.STDOUT by default.
Once I knew the problem, Google gave me a workaround. Add WSGIRestrictStdin Off and WSGIRestrictStdout Off in the apache config.
But wait. Paul, why the hell are you making command line calls from a web app!? Because the developers of GPG decided (likely after a few too many fermented beverages) that their "API" would be "call the gpg command and parse the output." This is also the reason why I've been working on this project off and on for two years (I've been writing to Santa each year for better GPG bindings).