Peter July 19, 2005 at 12:18 a.m.

Got a slight problem with runserver. Browsing to http://127.0.0.1:8000/ shows:

There's been an error:

Traceback (most recent call last):

File "/usr/lib/python2.4/site-packages/django/core/handlers/wsgi.py", line 184, in get_response
callback, param_dict = resolver.resolve(path)

File "/usr/lib/python2.4/site-packages/django/core/urlresolvers.py", line 85, in resolve
raise Http404, app_path

Http404

Adrian Holovaty July 19, 2005 at 12:47 a.m.

Peter: That's happening because your URLconf didn't find a match for the given URL (the root slash). See the brand-new Tutorial 3 for more information: http://www.djangoproject.com/document...

Jason Huggins July 19, 2005 at 12:56 a.m.

Peter, I got the same problem you were seeing. (Python 2.4, MySQL, Django Rev 188, Windows XP)

Thanks to the IRC logs, I found the solution here:
http://loglibrary.com/show_page/view/...

In tutorial 2, right before you are told to do "runserver", do this:

Windows:
set DJANGO_SETTINGS_MODULE=<YOUR_PROJECT_NAME>.settings.admin

Now, start the server, and go to:
http://localhost:8080/admin/

Jason Huggins July 19, 2005 at 1:07 a.m.

Whoops... if you do django-admin.py runserver, then is should be: http://localhost:8000/admin/

Looking back at the tutorial2 doc... It says exactly the same thing... However, the first time through, I didn't notice that the DJANGO_SETTINGS_MODULE setting needed to be switched from ".main" to ".admin", and the message in the console is misleading... The console says:

"Starting server on port 8000. Go to http://127.0.0.1:8000/ for Django."

Perhaps it should also mention that the admin interface is available at http://127.0.0.1:8000/admin/

Tomasz Małecki July 19, 2005 at 8:57 a.m.

I must say Django has more appeal for me than ruby on rails :) It's python, and templating engine is far more flexible ( it somehow resembles myghty).

Did you forgot to announce Tutorial 3 in weblog, or it's not THAT ready yet ?

Peter July 19, 2005 at 11:30 a.m.

Well, I'm following the directions from tutorial 2. I've:

export DJANGO_SETTINGS_MODULE=myproject.settings.admin
export PYTHONPATH=/space
django-admin.py runserver

and I still receive the error. It doesn't make much sense to me that I might need to follow the steps from tutorial 3 before I can do tutorial 2.

Anyone have any other suggestions as to how I can get this working?

Peter July 19, 2005 at 11:34 a.m.

Oy. My mistake. In following the note that pointed out the change to DJANGO_SETTINGS_MODULE, I just copy / pasted the line as shown. But that was for a Windows system and I'm running Bash under Linux. Changing the set to export fixes my problem.

Thanks to everyone who helped out...

Berry February 4, 2007 at 8:39 a.m.

Soon there will also be a mod_wsgi adapter that is apparently 2 times faster than mod_python. See: http://www.dscpl.com.au/wiki/ModWsgi

Graham Dumpleton February 19, 2007 at 8:05 a.m.

Django may claim to be WSGI compliant, but its means of relying on the environment variable DJANGO_SETTINGS_MODULE isn't truly in the spirit of WSGI and actually means you can't run two distinct Django applications at different mount points under the same web server where both need to run within the same Python interpreter and multiple threads are being used.

Thus in mod_python and mod_wsgi, if you want to run two distinct Django applications, you must configure those packages to run each application in a distinct Python interpreter. This only works because these packages use the Python C API underneath and can do this. Any web server written in pure Python and which provides a WSGI adapter will though not be able to manage this and thus you can't do it.

The Django folks really need to provide a way that this setting can be provided through the WSGI environ in place of expecting it to be set in os.environ.

Whether this is the only such reliance on information in os.environ I don't know. If there are others, they should also be addressed. If this is done then Django will be a more friendly WSGI application.