os.environ['DJANGO_SETTINGS_MODULE'] = ‘mysite.settings’

From 1.4 they use:

os.environ.setdefault(‘DJANGO_SETTINGS_MODULE’, ‘mysite.settings’)

This change will break mod_wsgi where multiple Django sites are being run in separate sub interpreters of the same process.

This is because setting os.environ actually sets the process wide environment variable and so when they second site starts up, it sees the environment variable set by the first and use of setdefault() means it isn’t overridden.

You can either change back to assignment rather than setdefault(), or delegate each site to a separate mod_wsgi daemon process group.

Thanks! I noticed that you reply pretty regularly to blog posts, Stack Overflow questions, etc. It seems that you’re everywhere and I commend you for how voraciously you support mod_wsgi.

That was my thought as well about mod_python vs. mod_wsgi. One thought I had: is it possible for mod_wsgi to detect that mod_python is loaded and to emit a big fat warning? In this case, it took me a while to realize that mod_python was enabled and I suspect that it had been enabled by default in CentOS 5.5, because I doubt that anyone in my company was using mod_python.

If you see my later post at http://marc-abramowitz.com/archives/2012/10/02/continuation-of-mod_wsgi-setup/, I did explore process groups a bit, although I’d call it trial and error and more getting lucky than actually understanding what I was doing

BTW, you should explore use of mod_wsgi daemon mode. It is a better way of doing things and allows you to separately define what user the web application process runs as, thereby avoiding needing to have Apache user able to write to directories, which could be a pain.

Rob

If you want to take out the timestamp, then look inside the .alfredextension bundle for a file called info.plist and then remove all the stuff that references theDate, etc.