update to Apache/mod_wsgi documentation

[mgbelisle]

The current documentation for Apache/mod_wsgi deployment has this as an example apache.wsgi file:

import os
import sys

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

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Even though the above works just fine, since the django.core.management contains the setup_environment() function, which sets the environment variables in a more standard way, I suggest that we change that part of the documentation to say this:

import inspect
import os
import sys


apache_dir = os.path.dirname(os.path.realpath(inspect.getfile(inspect.currentframe())))
project_dir = os.path.dirname(apache_dir)
if project_dir not in sys.path:
    sys.path.append(project_dir)

import settings
from django.core.management import setup_environ

setup_environ(settings)

from django.core.handlers.wsgi import WSGIHandler

application = WSGIHandler()

I tested out the above configuration with python 2.6.3 and it worked well. I don't know though, maybe finding the current directory then importing the settings is overly complicated. I'll let you decide.

Thanks,
mgbelisle

[Graham Dumpleton]

The better solution is to stop expecting people to work out for themselves what to put in the WSGI script file for WSGI interface. Instead Django should provide a more high level variant of django.core.handlers.wsgi.WSGIHandler() which is given the directory path for the project and then code within Django itself just does everything internally that it needs to to ensure that all works properly.

In other words, so long as Django is in sys.path, should be possible to say:

from django.core.handlers.wsgi import WSGIApplication

application = WSGIApplication('/some/path/to/directory/containing/settings/file')

The WSGIApplication callable object could have other arguments to allow alternate name for settings file etc as well. For example, using

from django.core.handlers.wsgi import WSGIApplication

application = WSGIApplication(directory='/some/path/to/directory/containing/settings/file', settings='production_settings')

This would eliminate the whole problem of poor documentation as Django would just do everything and users wouldn't be left guessing.

The Django code which implements this could also ensure that everything is done exactly the same as how runserver does things. That way there wouldn't be this problem of stuff working in runserver and then not in a WSGI hosting mechanism such as mod_wsgi.

[James Bennett]

The current recommendation is one that's known to work and consists of the minimum amount of configuration necessary to make Django work in the common case, so that's what should be in the documentation. And the refactoring suggested by Graham would be out of scope for 1.2 at this point, so this ticket doesn't belong on the milestone.

[Gabriel Hurley]

This is no longer a documentation issue since ubernostrum already rejected the change in the recommended wsgi file. If the refactoring of the WSGIHandler code et. al. is still on the table for some future Django version, then this ticket belongs in Core Framework as best I can tell.

[Carl Meyer]

This ticket is no longer relevant since r17022.

The discrepancies between runserver and a "real" WSGI deployment that Graham mentions are a real issue. One of those discrepancies (the double settings import) is already fixed with the new 1.4 manage.py (r16964). The other issue, the fact that runserver does model validation and thus imports many apps' models.py sooner than they would be imported in a live deployment, deserves its own ticket (if it doesn't already have one). I'm not fully convinced that the best answer there is for the standard wsgi.py to run model validation also, though that might be the simplest fix.