More fun with Python web development environments: The Quest for Quixote
So I was trying to avoid the secondary long-running process (a separate application server) by installing mod_python on the Mandrake test box. It’s running an Apache 1.3.26 server, so I downloaded the proper version of mod_python (2.7.8) and checked out the requirements. They are: Python 1.5.2, 1.6, 2.0 or 2.1 and Apache 1.3 (1.3.20 or higher recommended).
In order to configure to compile, you need: apxs (an Apache development library), Apache source code, and a Python installation (preferably without threads enabled). Ah… there’s the first rub.
The Python 2.2.1 installation was installed by Mandrake on its own, with default threads on. So do I recompile with no threads? Nah, it’ll probably break something that already uses it. Further, the mod_python docs say that you might experience weird shit with a thread-enabled Python installation, because Apache 1.3.x doesn’t use threading. That’s a risk I’m not willing to take.
I know! Since the specs say Python 2.1 anyway, why not get the 2.1.3 tarball and install from source without threads? Great idea! Lah-dee-dah. Done. So then I’ve got /usr/bin/python symbolically linked to /usr/bin/python2.2 (the system install), and /usr/local/bin/python linked to /usr/local/bin/python2.1 (my no-threads compile to be used only by mod_python). That’s, effectively, four executable Python locations, all of which are on the environment path for both superuser and regular users.
Wonderful, I’ve got all the right pieces, and know exactly where they are. Time to hit the command-line again:
[root@mybox mod_python-2.7.8]# ./configure –with-apxs=/usr/sbin/apxs –with-apache=/usr/src/apache_1.3.26 –with-python=/usr/local/bin/python
What? An error? [reading] Hrmn… no executable binary found at /usr/local/bin/python, huh? I might have to build Python, huh? Fucker. Maybe it’s tripping on the symbolic link… I’ll point it to the real file, that should work. Clear the config.cache, and:
[root@mybox mod_python-2.7.8]# ./configure –with-apxs=/usr/sbin/apxs –with-apache=/usr/src/apache_1.3.26 –with-python=/usr/local/bin/python2.1
What? The same error? If it’s not executable, why can I execute the fucking thing as any goddamned user under the sun? Because mod_python sucks a throbbing, fat cock, that’s why.
Okay, so “fuck mod_python” I say for the eighth (and hopefully final) time. Shake it off.
I talked to the guy at work that helped develop Quixote, and asked him about mod_python. Well, he’s never used it… he’s always used the mod_scgi Apache module, and says it’s much faster. Oh, but wait, it requires… guess… its own application server running as a separate long-running process behind Apache!
So why have I spent the majority of the day trying to install something:
- that utilizes the one concept I’m trying to avoid (another process)
- that offers no readily apparent advantage to the WebKit/application server solution I’ve successfully implemented many, many times
- that I’ll have to learn the syntactical nuances of to bring it up to speed with my current knowledge of WebKit
Well, I just installed scgi and Quixote. Time to fuck about with httpd.conf for a bit. If the Quixote application server is stout and stable (WebKit’s appserver is a bit shaky sometimes), then that–and only that–may be good enough to justify the effort.