Code

Opened 4 years ago

Closed 2 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

Description

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

Attachments (0)

Change History (6)

comment:1 Changed 4 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 4 years ago by jcd

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 4 years ago by ubernostrum

  • milestone 1.2 deleted

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 4 years ago by gabrielhurley

  • Component changed from Documentation to Core 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 3 years ago by baumer1122

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:6 Changed 2 years ago by carljm

  • Easy pickings unset
  • Resolution set to fixed
  • Status changed from new to closed
  • 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 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.