I am trying to update my 1.9 application to 1.10 and I am getting the following error on running all my unit tests:
Traceback (most recent call last): File
I updated to django 1.10.5 and the problem went away.
Go figure!
It could be that your base urls.py
has an included urls.py
that has a $ sign mistakenly put into it. This will cause issues with the urlresolvers. Scan your included urls and make sure that there are no dollar signs in them.
Another thing to look out for is if you have any views that throw exceptions in any of your urls.
Your LANGUAGE_CODE
setting is set to en_gb
. Notice the underscore character. It should be en-gb
.
I encountered this as well, and I narrowed down the cause. I think it's a regression in Django, but I don't have time to write up a full bug report. Here's what I know.
Django waits until the first call to django.urls.reverse
to populate all the namespaces to a cached dict
.
There's been some changes to that population procedure recently.
They added a populating flag that is set to True when you start populating, and is shared across calls to reverse
. If the population process happens to make a call to django.urls.reverse
, the flag will prevent infinite recursion.
The population process involves importing URL patterns - the urls.py
files you have in your apps. If anything during that import process raises an exception, e.g. an undefined name at the top-level of a module in my case, the population algorithm doesn't catch that, and just stops outright, and leaves the populating flag to True. That error, at least for me, was propagated to the top level and I saw it in test runner output.
All subsequent calls to django.urls.reverse
raise a NoReverseMatch
error for the en-us
namespace. Following the code, this is because at the start of the population procedure, if the populating
flag is truthy, the process just returns and returns the cached namespace dict, which is empty, causing a KeyError for en-us
, causing a NoReverseMatch
for en-us
.
You should look at the errors that occurred before the first NoReverseMatch
to find your culprit. For more info, I think this is the commit that introduced the regression. It has a link to the Django issue it fixed. I think the fix would be to set the populating
flag to False in case of an exception, but I'm not sure.
Run django system check command it may show the underlying problem:
python manage.py check