The whole reason the 32/64 bit issues comes up is because ‘python’ command line program is only installed as 32 bit and so everything runs as 32 bit and when people are using it initially don’t see any problems. The MacOS X version of Apache however is a 64 bit capable application and so will default to running 64 bit if you have 64 bit cpu. The distutils package in Python though only builds 32 bit extensions, so unless third party packages have been made MacOS X aware in some way to get around that problem, they will fail to build for all architectures. Some times the simplest thing to do is to install your own version of Apache from source code, as it will only be 32 bit and thus avoid all the problems.

Pretty well all the issues are documented some where as is a reference to mailing list for mod_wsgi. Of course, getting people to read documentation and asking questions on the correct forum is the challenge. :-)

The whole reason the 32/64 bit issues comes up is because ‘python’ command line program is only installed as 32 bit and so everything runs as 32 bit and when people are using it initially don’t see any problems. The MacOS X version of Apache however is a 64 bit capable application and so will default to running 64 bit if you have 64 bit cpu. The distutils package in Python though only builds 32 bit extensions, so unless third party packages have been made MacOS X aware in some way to get around that problem, they will fail to build for all architectures. Some times the simplest thing to do is to install your own version of Apache from source code, as it will only be 32 bit and thus avoid all the problems.

Pretty well all the issues are documented some where as is a reference to mailing list for mod_wsgi. Of course, getting people to read documentation and asking questions on the correct forum is the challenge. :-)

[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] The following error occurred while trying to extract file(s) to the Python egg
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] cache:
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] [Errno 13] Permission denied: ‘“‘
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] The Python egg cache directory is currently set to:
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] “/.python-eggs/“
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1]
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] Perhaps your account does not have write access to this directory? You can
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] change the cache directory by setting the PYTHON_EGG_CACHE environment
[Sat Aug 15 23:53:29 2009] [error] [client 127.0.0.1] variable to point to an accessible directory.

I fixed that by adding a “user=myuser” arg to the WSGIDaemonProcess directive (this after also creating ‘chmod 777′ dirs owned by the web user, which didn’t work, and which I still don’t understand). I also tried fixing this using os.environ(‘PYTHON_EGG_CACHE’) in my myapp.wsgi script, and also using the WSGIPythonEggs directive mentioned here: http://code.google.com/p/modwsgi/wiki/Applicati… Nothing worked until I found “user=”. BTW, I’m using mod_wsgi 2.5, installed (and dl’d for that matter) using your exact commands, because I was pretty sure going into it that we had near-identical macbook pros.

I’m using the Apple-supplied python installation. I initially created my virtualenv using your instructions exactly, but went back to add ‘–no-site-packages’ when I started having issues loading mysqldb. Then I actually just uninstalled mysqldb from the system, did the “export ARCHFLAGS” like the modwsgi site says to do to get around arch issues, built a new version of the module from source, and now I’m getting:
“[Sun Aug 16 13:23:49 2009] [error] [client 127.0.0.1] raise ImproperlyConfigured(“Error loading MySQLdb module: %s” % e)
[Sun Aug 16 13:23:49 2009] [error] [client 127.0.0.1] ImproperlyConfigured: Error loading MySQLdb module: dynamic module does not define init function (init_mysql)
“
I guess it’s progress, but again, hardly simple. I haven’t finished googling the issue to see what the fix is. It’s v. 1.2.3c1 of the module. I guess it’s true that this is perhaps mostly an arch-level issue outside the control of modwsgi, but why is it that I can write CLI scripts with Python all day long and never run into any of these issues? I’m not blaming modwsgi or questioning what you’ve said, I really just want to understand this more clearly, because it’s driving me insane, and that’s not enjoyable.

I haven’t given much thought to arch up to now. Perhaps it’d be easier to just build *everything* from source: apache, python, etc. Have a bare-bones base python install, and just easy_install modules in virtualenv as needed. Advice/opinion hereby solicited. I’m not sure how to reach Graham — I’m sure there’s a mod_wsgi google group, so I’ll see what I find.

I have no idea what you’re talking about with regards to the python egg cache. I also didn’t run into architecture related issues; so I’d be interested to hear what those are. Are you hand compiling it? Is it the built in version? I know Graham has outlined some of the issues here: http://code.google.com/p/modwsgi/wiki/Installat… — the biggest one is the fact the python.org versions of python don’t ship 64 bit compatible.

Frankly, most of the issues I’ve run into are problems with the multi-architecture mess which is leopard+python builds — not mod_wsgi, mod_wsgi just shows the problems. Having a 64 bit apache, and a 32 bit version of Python (which python.org ships) doesn’t exactly make things easy for mod_wsgi which has to work with both.

As for the dev vs. production issue — I run the same config on the server (+ or — minus some tweaks) as I do on the desktop.

I can understand your pain, which is why I tried to be explicit as possible. Have you talked to Graham (the mod_wsgi maintainer) about any of this?

One other question: what are the major differences between using mod_wsgi for the dev work and using the django dev server? Is that documented somewhere?

Sorry man. Don’t mean to rant on your parade. Good post, as usual.