[mod_python] problems installing on OS 10.5

2009/3/9 Dan Yamins <dyamins at gmail.com>:
>
>>
>>
>> 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.
>
> Well -- I guess I'm using the GCC that came with Xcode.    The python I'm
> using the is the build of 2.5.2 that I got as a binary from www.python.org,
> the frameork install that's gets installed in:
>
> /Library/Frameworks/Python.framework/Versions/Current/bin/python
>
> I've never had a problem building 64 binaries before ...

The binary MacOS X installer from www.python.org doesn't have 64 bit
architecture built into the framework and thus why it fails. This is
again mentioned in the mod_wsgi documentation. :-)

>> If it is CGI, then see about turning it into a WSGI application.
>
> So, you're saying that the object of not having to have a new python
> interprerter opened for every request is achieved properly if I use wsgi?
>
>
> Thanks very much for this information below, though I think I need to
> understand the wsgi model sort of from scratch ...

It isn't just the WSGI model, but how it is hosted. Technically you
can host WSGI within CGI and a separate process is still created for
each request. Even Google App Engine which supports WSGI has a mode
whereby process only used for one request. Other hosting mechanisms,
including a different mode of Google App Engine support the
application being persistent.

For a discussion about process/thread models available with mod_wsgi
have a read of:

  http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Graham

> Dan
>
>> 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
>
>