I have found a ticket already open for this problem (http:// code.djangoproject.com/ticket/13684), The problem was in fact that I had a settings.py file and a module called settings with default and local settings residing inside it. There must have been some confusion and moving the settings.py file into the module resolved the name conflict and allowed Django to run correctly.
On Jun 11, 1:57 pm, bruno desthuilliers <bruno.desthuilli...@gmail.com> wrote: > On 11 juin, 00:45, Marcus Whybrow <marcus.whyb...@gmail.com> wrote: > > > > > > > mod_wsgi (pid=2639): Exception occurred processing WSGI script '/home/ > > webapps/apache/tinygraph.wsgi'. > > Traceback (most recent call last): > > File "/home/webapps/.virtualenvs/tinygraph/lib/python2.6/site- > > packages/Django-1.2.1-py2.6.egg/django/core/handlers/wsgi.py", line > > 241, in __call__ > > response = self.get_response(request) > > File "/home/webapps/.virtualenvs/tinygraph/lib/python2.6/site- > > packages/Django-1.2.1-py2.6.egg/django/core/handlers/base.py", line > > 142, in get_response > > return self.handle_uncaught_exception(request, resolver, exc_info) > > UnboundLocalError: local variable 'resolver' referenced before > > assignment > > > I have just set up a brand new Django project called tinygraph and I > > am using WSGI and virutalenv in combination. > > > I have took a peak at the Django source code and resolver is not > > assigned a value unless a urlconf is set, > > I though this might be because I had defined no url tuples in the > > urlpatterns variable, however that did not solve the issue. > > NB : r12953 here but since line 142 seems to match your traceback I > guess this file didn't changed. > > Had a look too. 'resolver' is first assigned at line 76, so the real > exception must happen in lines 74:76: > > urlconf = settings.ROOT_URLCONF > urlresolvers.set_urlconf(urlconf) > resolver = urlresolvers.RegexURLResolver(r'^/', > urlconf) > > You could get more info step-debugging these lines. Anyway - the fact > that you get an UnboundLocalError at line 142 shadowing the real > exception is an obvious bug - it ShouldntHappen(tm) -, so I strongly > suggest you fill a bug report (nb : just checked on the trunk, a > couple things changed but AFAICT the problem is still here). > > > I just cannot figure it out, I am sure it will be something really > > simple, > > Thanks for any help, > > In the meantime, you can try patching django/core/handlers/base.py to > get the real exception, solve it and revert. Replace line 142 with a > plain "raise" instruction so you short-circuit any other code and > rerun your code. You should get a more useful error message. > > FWIW, what happens when using the dev server ? > > HTH -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
