This will get the env from the Apache conf and set it before a request to make sure that the proper settings file is loaded.

However, in Django 1.7, this broke because django.setup() is now run as part of django.core.wsgi.get_wsgi_application() and this causes the settings file to be loaded before the first application() call (first request).

Previously, the loading of the settings file seems to happen with the first application() call, django.core.wsgi.get_wsgi_application()().

Debugging this was actually more difficult than it seems. I initially just got a 400 BAD REQUEST error after upgrading, with no errors in the logs. It took a long time to realize my my custom settings file wasn't being loaded and so ALLOWED_HOSTS weren't being loaded either.

After finding out it was a changed behavior in wsgi loading that was causing the problem, fixing the problem was straightforward, but I recommend updating the documentation with this change in Django 1.7 so that others wouldn't run into this issue.

Here's the fixed version that also works with 1.7 (and earlier) if someone is interested:

I ran into this problem as well and created a pull request (​https://github.com/django/django/pull/5271) to address the issue. Although I realize I didn't address the original submitter's request for documentation about how wsgi loading is handled, I did provide changes to the documentation at explains and provides a working solution that is also backwards compatible for doing what the original submitter was trying to do along with showing how to pass arbitrary variables from the Apache configuration to Django.

Where you need a process level global variable inherited from some key set in the Apache configuration, what you are best to do is ensure you are running the Django application in a mod_wsgi daemon process group of its own (forced to use main interpreter application group), and then base any in code decisions on the name of the daemon process group you used in the Apache configuration.

For example, you could even have the name of the Django settings module be the name of the daemon process group.

FWIW, this unexpected change has occurred in a previous Django release as well. See ticket #21486. The response in that ticket was to avoid importing settings.py during a call to get_wsgi_application() such that the original pattern would continue to work. I'm not sure if this is still feasible today.

I appreciate the expertise and knowledge Graham Dumpleton brings to the table. But it feels a tad limiting that one can't freely pass an arbitrary amount of environment variables from Apache to Django. Some deployment strategies, such as Twelve-Factor App (Not Django specific ​http://12factor.net/config) specifically recommend configuring web apps through environment variables. Is using environment variables really just not possible with mod_wsgi?

If my application has exactly one variable to read, it is difficult to make multiple decisions on this. For example, my application loads settings slightly differently in production vs debug/development mode. This is to ease configuration for other, perhaps new, developers. With just one available variable that is always set it becomes difficult to do this.