Opened 7 years ago

Closed 5 years ago

#12056 closed Cleanup/optimization (fixed)

update to Apache/mod_wsgi documentation

Reported by: mgbelisle Owned by: nobody
Component: Core (Other) Version: 1.1
Severity: Normal Keywords: mod_wsgi, setup_environ
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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

import settings
from import setup_environ


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.


Change History (6)

comment:1 Changed 7 years ago by grahamd

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

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.

comment:2 Changed 7 years ago by Cliff Dyer

Triage Stage: UnreviewedDesign decision needed

comment:3 Changed 7 years ago by James Bennett

milestone: 1.2

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.

comment:4 Changed 6 years ago by Gabriel Hurley

Component: DocumentationCore framework

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.

comment:5 Changed 6 years ago by Peter Baumgartner

Severity: Normal
Type: Cleanup/optimization

comment:6 Changed 5 years ago by Carl Meyer

Easy pickings: unset
Resolution: fixed
Status: newclosed
UI/UX: unset

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 (r16964). The other issue, the fact that runserver does model validation and thus imports many apps' 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 to run model validation also, though that might be the simplest fix.

Note: See TracTickets for help on using tickets.
Back to Top