[mod_python] problems installing on OS 10.5

2009/3/9 Dan Yamins <dyamins at gmail.com>:
>
>>
>> Use source code for mod_python from mod_python subversion repository
>> as that version includes all MacOS X Leopard fixes.
>
> Graham, thanks for your quick reply.   I already tried this, actually, as
> one of the pages I found said that the svn trunk had the fixes in it.
> However, I wasn't able to get anywhere with this approach since I couldn't
> compile the code I got from trunk.
>
> If you're interested in the error it was, at the "make stage:
>
> "
> daniel-yaminss-macbook-pro:mod_python-trunk danielyamins$ make
>
> Compiling for DSO.
>
> <snip ...>
>
> /Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/pyport.h:761:2:
> error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
> config?)."
> lipo: can't figure out the architecture type of:
> /var/folders/RL/RL57YSioGTWoMJh4O1-SFk+++TI/-Tmp-//ccKJqCJ6.out
> apxs:Error: Command failed with rc=65536
> .
> make[1]: *** [mod_python.so] Error 1
> make: *** [do_dso] Error 2
> "
>
> I decided not to follow up on this, but if it's the only way to get the
> fixes, I'll try to figure it out.

This is because you are trying to use MacPorts version of Python, or
one you installed yourself, which doesn't include all architectures as
part of the Python installation. That or you are using version of GCC
which didn't come with MacOS X and it doesn't support generation of 64
bit binaries properly. This is covered in the mod_wsgi documentation.

Whose Python installation are you using? If your compiled from source
code, what 'configure' line did you use with Python when installing
it?

>>Even better, if you are only wanting to host an application that
>>support WSGI interface and not using mod_python specific APIs, use
>>mod_wsgi instead. Pretty well all Python web applications and
>>frameworks support WSGI interface these days and mod_wsgi is arguably a
>> better solution these days
>
> Well -- here is what I want to do -- tell me if mod_python is the right
> solution -- perhaps I'm barking up the wrong tree entirely.   I've built an
> application currently using CGI.   It's quite slow, in part because each
> request to the application requires the importation of a number of fairly
> heavy modules.   (e.g. it will take 3-4 secs to load the page not because of
> the dynamic code running in each cgi module but because of the overhead of
> having to restart python interpreter and reload all the modules the code
> uses).  I was hoping using mod_python as a way to not have to restart the
> python interpreter.  But maybe mod_wsgi is the right thing? Sorry for my
> ignorance, and happy to switch approaches if wsgi would be better for my
> need.

If it is CGI, then see about turning it into a WSGI application. The
main difference is that the request environment is passed as a
parameter into your application rather than it being in os.environ.
When generating a response, you need to return it from the
application, rather that just using 'print' to produce it. Another
thing that may catch you is that since now persistent if using
mod_wsgi, you need to ensure you don't preserve temporary working
state in variables that could be incorrectly accessed by subsequent
request. Otherwise usually not too hard to convert a CGI application
to WSGI.

Finally, if your scripts are multithread safe, you would want to
ensure that you use mod_wsgi daemon mode with only a single threaded
process.

Graham