"Conflicting models in application" RuntimeError for same model with different paths

[Daniel Hahler]

When I run tests using manage.py test, the test file project/app/tests.py is used/imported with __name__ = "project.project.app.test".

When using a relative import in tests.py then, the model appears to get registered as project.project.app.model.

After the database for the tests is being setup, I get the following error:

RuntimeError: Conflicting 'model' models in application 'app': <class 'app.models.Model'> and <class 'project.project.app.models.Model'>.

It refers to the same Model, but with different class paths.

This is triggered by / caused when using an relative import from the tests.py file: from .models import Model.

I am running manage.py from the first "project" directory.

sys.path contains the directory .../project/project and not the directory where project.project.app would be rooted.

With Django 1.6 the __name__ of tests.py during the import is the same, but there's no error, since there is no apploader that verifies uniqueness using the labels/names.

I could not reproduce it with a simple new project/app in Django 1.7.

ERROR: project.project.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: project.project.app.tests
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "…/project/app/tests.py", line 23, in <module>
    from .views import HomePageView
  File "…/project/app/views.py", line 6, in <module>
    from .models import Movie, Collection
  File "…/project/app/models.py", line 51, in <module>
    class Person(models.Model):
  File "…/django-master/django/db/models/base.py", line 299, in __new__
    new_class._meta.apps.register_model(new_class._meta.app_label, new_class)
  File "…/django-master/django/apps/registry.py", line 201, in register_model
    (model_name, app_label, app_models[model_name], model))
RuntimeError: Conflicting 'person' models in application 'app': <class 'app.models.Person'> and <class 'project.project.app.models.Person'>.

[Daniel Hahler]

I had initially reported it for pytest_django: ​https://github.com/pelme/pytest_django/issues/75

There is more information available (e.g. the full output from ipdb's where).

[Daniel Hahler]

The different paths were caused by an __init__.py file in the root directory.

[Daniel Hahler]

But with project/project/__init__.py (the default startproject layout), the error from Django persists, but the "previous" model gets recognized as project.app.models.Model.

[Aymeric Augustin]

The same model gets imported through two different paths. That used to be possible, but it's forbidden in Django 1.7.

Django 1.6 and earlier used some rather dark magic to return the same object instead of a copy, which is what Python does when you import a module through different paths.

With the information you've provided, I'm not exactly sure why you end up in this situation, and nothing points to a bug in Django.

Inserting import sys; print(sys.path) just before the point where Django raises an error may help. You could also inspect the content of the app registry (from django.apps import apps) at that point.

[Daniel Hahler]

Thanks for your help!

I think I figured it out (at least a bit more): because of the init.py files above the app (in the project dir), the relative import uses the whole package name ("project.app").

Django maybe manages it to get the name setup without using the whole of the package name.

For now, I have removed the init.py files from the project dir (and above), so each app is considered to be a separate package.

Regarding the app-loading behavior: if Django would also use the whole package name for the import (which appears to get shortened?!) or would track it for later comparison, that might help here.

(Please note that I might have overseen some __init__.pyc while removing __init__.py files before)

[Aymeric Augustin]

Here's my theory:

• The current working directory is automatically added to PYTHONPATH.
• You're doing import app.foo.bar somewhere.

This starts an import from your working directory, which is inside the projet root directory.

[Daniel Hahler]

The current working directory is automatically added to PYTHONPATH.

That does not appear to make a difference, since I tried it with from different directories.

You're doing import app.foo.bar somewhere.

That does not appear to be the case.

From my understanding, a relative import will just use the full package name always.

In register_model it looks like follows: via the relative import (project/project/app/tests.py):

('register_model', u'app', <class 'project.app.models.Person'>)

And the later model appears as:

('register_model', 'app', <class 'fake.Person'>)

This gets done via ModelState.render.

When using runserver instead of tests, the model appears as:

('register_model', 'app', <class 'app.models.Person'>)

It gets setup via django/apps/config.py / import_module / INSTALLED_APPS then.

[Aymeric Augustin]

I suspect __fake__.Person is just a misdirection caused by the migrations framework.

You're seeing alternatively project.app.models.Person and app.models.Person. AFAICT that means that both project and project/project are on PYTHONPATH. Could you print sys.path in register_model and report the results?

[Daniel Hahler]

Yes, both project and project/project are in sys.path:

sys.path looks as follows when the exception gets raised (and also before the relative imports):

'/project'
'/project/virtualenv/src/autocomplete-light'
'/project/project'
'/project/virtualenv/src/django-grappelli'
...

But also with only project/project on sys.path (depending on the package / init.py layout), the problem persists: it's just different then how the conflicting model is named.

I suspect fake.Person is just a misdirection caused by the migrations framework.

Does this mean, it should not show up as "fake." here?

[Aymeric Augustin]

Having a directory and a subdirectory is PYTHONPATH isn't supported any more. See the third paragraph in the release notes: ​https://docs.djangoproject.com/en/dev/releases/1.7/#app-registry-consistency. You must be setting PYTHONPATH explicity to end up in this situation. Since you're using relative imports, you should be able to remove this customization. Maybe you'll have to fix a few imports.

Once you've fixed that, if you're still encountering issues with __fake__.Person, could you reopen the ticket? By "misdirection" I meant that it was either irrelevant to the first problem or a totally different problem.

Thanks for bearing with me while we debug this!

[Daniel Hahler]

Having a directory and a subdirectory is PYTHONPATH isn't supported any more.

Let me quote myself:

But also with only project/project on sys.path (depending on the package / init.py layout), the problem persists

You must be setting PYTHONPATH explicity to end up in this situation.

No. It's just that I have pip install -e .ed the project directory, and then it depends on the init.py files layout.
I am not setting PYTHONPATH explicitly somewhere (I have checked virtualenvwrapper and envdir).

Since you're using relative imports, you should be able to remove this customization. Maybe you'll have to fix a few imports.

The workaround is clear: using non-relative imports (when using the Django or py.test testrunner), or removing the init.py file from the root directory - if I recall/remember it correctly.
It's just a bit inconvenient having to use the app name in the app itself for imports in the tests.

Using relative imports in the app's views.py is fine.

Thanks for bearing with me while we debug this!

I thank you for your help and support - and still hope that I am not just doing something stupid.. ;)

(FWIW, I am now getting the following error with manage.py test (but not with py.test) - django being a symlink to django-master:

ImportError: 'test_http' module incorrectly imported from '…/django-master/django/contrib/sitemaps/tests'. Expected '…/django/contrib/sitemaps/tests'. Is this module globally installed?

That one is coming from /usr/lib/python2.7/unittest/loader.py though, and just popped up when I've tried to look for the current state of __fake__.Person models).

Let me once repeat, to make it clear, I think that the main issue is that a relative import causes Python to use the whole package name for the module, but the imports through Django somehow only use the app's path relative to the main project path (with the project prefix being removed).

[Aymeric Augustin]

First, a question: are you using explicit relative imports (from .xxx import ...) or implicit relative imports (from xxx import ...)? If you're using the latter form, you might be accidentally using absolute imports.

Let me explain a bit.

Assume the following structure:

root/
root/__init__.py
root/foo/
root/foo/__init__.py
root/foo/bar.py
root/foo/baz.py

Assume both root and foo are on PYTHONPATH (bear with me for a moment).
Assume foo/__init__.py contains import bar and that line is executing.
Assume foo/bar.py contains from baz import .... Then an absolute import will be performed, since baz.py is found in foo which is on PYTHONPATH, and the baz module is registered as 'baz' in sys.modules.
On the other hand, if foo/bar.py contains from .baz import ..., then a relative import will be performed, and the baz module is registered as 'foo.baz' in sys.modules.

This bears some resemblance with the symptoms you're describing and doesn't involve dark magic in Django. (There used to be some dark magic in this area, but we removed it in 1.4.)

---

Now, regarding your particular situation, pip install -e . has the effect of adding . -- the current directory at the moment you're issuing the command -- to PYTHONPATH. There's a variety of way to set PYTHONPATH and that's why I was insisting on printing sys.path.

Considering your project layout, I believe only the "outer" project folder -- the one that contains manage.py -- should be on PYTHONPATH.

If I read you correctly, the "inner" project folder -- the one next to manage.py -- is also on PYTHONPATH because you added it with pip install -e. When you're executing management commands, such as running the tests, with manage.py, Python automatically adds the folder containing manage.py -- the "outer" project folder -- to PYTHONPATH.

That's one way you can end up with the two project folders on PYTHONPATH and suffer from the ambiguity between absolute imports and implicit relative imports I described above. The answer is to always use explicit relative imports. Implicit relative imports are a footgun.

---

Finally, your analysis in bold is inconsistent with what I know about Django. Attaching a minimal sample project with reproduction instructions would help me, or someone else, figure out what's going on.

[Aymeric Augustin]

Closing again, because I don't think there's a bug in Django. I will to investigate more if you can provide a minimal project exhibiting this issue. Thank you!

[Daniel Hahler]

I have investigated a bit more, and it appears that the main problem is having
an __init__.py file next to manage.py, which causes the testrunner /
unittest to add its directory to sys.path.

Please note that this issue appears to be related to running tests via
manage.py test only!

From the ​1.7 release notes:

It isn’t possible to import the same model twice through different paths any more.

Fair enough, and that's basically what this issue is about - so it would just
not be supported anymore.

However, the release note also state:

As of Django 1.6, this may happen only if you’re manually putting a directory
and a subdirectory on PYTHONPATH. Refer to the section on the new project
layout in the 1.4 release notes for migration instructions.

Since I am not manually changing PYTHONPATH it appears to be an issue with
Django's testrunner.

I have create a test repo for this issue:
​https://github.com/blueyed/test-django-issue-22280

Let me elaborate how to reproduce it:

As for a sample test project, just create a new one using "startproject" and
"startapp", and then add an additional __init__.py next to manage.py:

project
├── app
│   ├── admin.py
│   ├── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── __init__.py  (added additionally)
├── manage.py
└── project
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

Running the tests will fail:

ERROR: project.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: project.app.tests
[...]
ImportError: No module named app.tests

That's understandable, because now there's ../project and
../project/project on sys.path, which is ambiguous.

Let's rename the top-level project folder to proot.

manage.py test runs fine now.

But when you then use both from app.models import Model (in your project,
e.g. via manage.py) and from .models import Model in the tests, it will
result in the error:

======================================================================
ERROR: proot.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: proot.app.tests
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 257, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 235, in _get_module_from_name
    __import__(name)
  File "/tmp/djt/proot/app/tests.py", line 3, in <module>
    from .models import Model
  File "/tmp/djt/proot/app/models.py", line 3, in <module>
    class Model(models.Model):
  File "/tmp/djt/venv/local/lib/python2.7/site-packages/django/db/models/base.py", line 286, in __new__
    new_class._meta.apps.register_model(new_class._meta.app_label, new_class)
  File "/tmp/djt/venv/local/lib/python2.7/site-packages/django/apps/registry.py", line 201, in register_model
    (model_name, app_label, app_models[model_name], model))
RuntimeError: Conflicting 'model' models in application 'app': <class 'app.models.Model'> and <class 'proot.app.models.Model'>.

I've been running into this, because my project layout is basically everything
from project/project moved to project.

DJANGO_SETTINGS_MODULE=settings
project
├── app
│   ├── admin.py
│   ├── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── __init__.py
├── manage.py
├── settings.py
├── urls.py
└── wsgi.py

As a side-note, the ​release notes for 1.4 about the new project layout, which are references from the 1.7 release notes, mention:

If settings, URLconfs and apps within the project are imported or referenced
using the project name prefix (e.g. myproject.settings, ROOT_URLCONF =
"myproject.urls", etc), the new manage.py will need to be moved one directory
up, so it is outside the project package rather than adjacent to settings.py
and urls.py.

This implies that it's supported to have them available without the project
name prefix?!

But in the end the whole issue appears to be with unittest / Django's
testrunner/unittest only, which manipulates sys.path when there is an
__init__.py next to manage.py.

I've tested it now with both master and 1.7.x.

[Aymeric Augustin]

Your examples look like the directory containing the outer "project" or "proot" directory in on PYTHONPATH.

I'm saying this because you have module names like project.app.tests and proot.app.tests in your examples.

Can you confirm?

There's no good reason for that. Only "projet" or "proot" should be on PYTHONPATH.

The __init__.py is a red herring. It just makes the error more confusing.

[Daniel Hahler]

Your examples look like the directory containing the outer "project" or "proot" directory is on PYTHONPATH.

No. This is a new shell, and I have created the virtualenv with virtualenv venv explicitly.

The init.py is a red herring. It just makes the error more confusing.

No, with init.py the tests fail, and removing it make them run - because then /tmp/test-django-issue-22280 gets not added to sys.path and the model/app gets not imported with different paths.

I have added a Makefile to the test repo. You should be able to reproduce it with:

1. git clone https://github.com/blueyed/test-django-issue-22280
2. cd test-django-issue-22280
3. make test

It uses the 1.7c1 tarball. You may want to use a local checkout instead.

[Aymeric Augustin]

Thanks for the example project. I ran it and reproduced the error:

RuntimeError: Conflicting 'model' models in application 'app': <class 'app.models.Model'> and <class 'proot.app.models.Model'>.

It's pretty clear in this error that the same Model class was imported through two different Python paths: app.models and proot.app.models. That is always an error and it's purposefully forbidden in Django 1.7. However, the reasons why this happens aren't obvious.

If you aren't convinced that it's always an error, learn about ​the double import trap and come back.

With python -Wall I got this warning:

test-django-issue-22280/proot/app/models.py:3: RemovedInDjango19Warning: Model class app.models.Model doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.

It's referring to app.models.Model which is the expected path. So I went ahead and added 'app' to INSTALLED_APPS.

Then I got this warning:

test-django-issue-22280/proot/app/models.py:3: RemovedInDjango19Warning: Model class proot.app.models.Model doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.

Note that it's referring to proot.app.models.Model now which is unexpected.

To debug this further, I added from pprint import pprint; import sys; pprint(sys.path) in app/models.py.

As expected, that shows that the module is imported twice. The first time, sys.path contains test-django-issue-22280/proot, and then venv and system stuff. The second time, it contains test-django-issue-22280, test-django-issue-22280/proot, and the same venv and system stuff.

That's where the __init__.py begins to make a difference. Once test-django-issue-22280 is added to sys.path, the __init__.py makes in possible to import Python objects as proot.xxx, and the double import trap appears.

So the question becomes -- what added test-django-issue-22280 on sys.path? I think it happens somewhere in DiscoverRunner.build_suite. I don't understand that code very well.

I'm going to stop there for now because I don't think it's an app-loading regression. App-loading just raised an error, as intended, in one of the situations it was designed to prevent.

Considering that you're the only person to have complained about this, and that your example contains fairly weird stuff, I'm not marking this as a release blocker. For example, why on Earth would you import a model in manage.py? I don't think it's relevant here, but seriously, I wasted a lot of time just to find that out...

[Daniel Hahler]

Thanks for your time, investigation and explanations.

Just to clarify:

For example, why on Earth would you import a model in manage.py? I don't think it's relevant here, but seriously, I wasted a lot of time just to find that out...

Sorry, that was meant to simulate loading it early, similar to how e.g. autocomplete_light's discovery (might) work(s), and I've thought it would be necessary to trigger it.

But just having it in INSTALLED_APPS (and removing it from manage.py) also triggers this issue. I have updated the test project accordingly, which is now only weird in the regard that it has a __init__.py next to manage.py.

[Carl Meyer]

This is due to ​https://github.com/django/django/blob/master/django/test/runner.py#L71 and following, which is admittedly ugly (see the comment), but I'm also not sure that we have a better option.

Unittest has a concept of a "top-level dir" which it will place on sys.path and import things relative to. You can specify this explicitly (and we provide a way to do that via manage.py test with the -t option). If you don't, unittest's default is to set the top-level dir to be the immediate containing directory of the test file being run. Unittest's default choice is usually wrong (for any test file that is not actually a top-level module; and most Django test files are not, because they tend to be within apps) and we did not want to require everyone to specify the -t option explicitly all the time. So we walk up the directory tree looking for __init__.py files and consider the top-level dir to be the first dir we find that doesn't have one. This is usually correct, if there are __init__.py files where there should be and none where there shouldn't be. The OP here has an __init__.py file where there should not be one, thus our auto-detection of the top-level dir breaks.

Another problem with our best-effort approach here is that PEP 420 allows Python packages without __init__.py files; as usage of versions of Python including PEP 420 support (3.3+, I think?) increases and people start leaving out __init__.py files in their projects, I expect we will see more reports of our top-level-detection code breaking.

It would be nice if unittest had an option to say "assume sys.path is already set up correctly and don't add anything to it", since in a normal Django project structure the location of manage.py already adds the correct top-level dir to sys.path anyway, but AFAIK unittest has no such option. If you pass it a dotted module path instead of a file path, it doesn't add anything to sys.path - but unfortunately as noted in our code comment, given a single top-level module name unittest chooses to treat it as "file path" rather than "dotted module path" and go ahead and make the sys.path addition (and then by default it adds the given directory, rather than its containing directory, to sys.path). So we need to pass it a correct top-level directory, and this __init__.py search is our best effort to do so.

We could request changes to unittest's API to help us here; those changes wouldn't actually help us for quite some time, though, given that we are tied to supporting the version of unittest in the Python 2.7 stdlib, which won't include any such changes.

So given the unittest API limitations we are working within, here are the options I can see for improvement:

1. We could just add better documentation of what our test runner does, and the implication that you need to have __init__.py files located within all your Python packages, but not in directories that are not Python packages (i.e. the directory containing manage.py).

2. We could detect by looking for manage.py instead of looking for __init__.py files. I include this for completeness, but it is a bad solution. It would break when running tests for apps outside a "Django project", it would break for any project that doesn't use manage.py or has renamed it (both perfectly valid things to do), etc.

3. We could try detecting the top-level dir by walking up the filesystem and checking each directory to see if it is already on sys.path, and assuming it is the top-level dir if it is. I _think_ this should work at least as correctly as the current approach, but would need to play with it to be sure it handles various edge cases properly (running tests in out-of-project apps, etc). It should fix the OP's scenario. Choosing this approach would mean that you can only run Django tests if you've already set up sys.path - this should be fine for people using manage.py test, but it could break some unusual approaches used by some projects that currently rely on unittest's sys.path additions; so it would have to be considered a potentially backwards-incompatible change.

4. As a variant of (3), we could try to minimize the backwards-incompatibility by first looking for "directory already on sys.path", and if we walk up to the fs root and haven't found one, we could fall back to the current __init__.py finding.

I don't expect to write a patch for this in the near future, but as the person responsible for that code I will commit to reviewing (and possibly committing) any patches that may be proposed.

[Malik A. Rumi]

1. Thanks to all of you for your detailed and ongoing comments which helped me understand what is going on.
2. Blueyed, you are no longer the only one having this issue. I'm not sure that's good news.
3. There are some significant differences in our experiences, however:

a) I am still pretty new to both Python and Django, so my analytical prowess is not as developed as the rest of you. I may be over reporting irrelevant information and under reporting the relevant.
b) I am on a Windows 8.1 machine with Python 2.7 and Django 1.7c1.
c) I have not run any tests whatsoever. This all started when I ran makemigrations for the first time. I got a whole series of errors, and shifted to python manage.py shell, where the errors still came up. I was working through them one by one until I got to this one:

{{{ File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line 201, in register_model (model_name, app_label, app_models[model_name], model))

RuntimeError: Conflicting 'articles' models in application 'usconst': <class 'apps.usconst.models.Articles'> and <class 'Baillee.apps.usconst.models.Articles'>.}}}

After reading this ticket, I remembered adding my G: drive to Pythonpath. I can't recall now why I did that, but it must have been as a result of an earlier error and trying to cover all bases. So I removed that, restarted the machine, ran the shell, fully expecting that to resolve my isssue... and got the same error.

I do not have __init.py next to manage.py.
I installed everything with pip. I did not use .e or any other flags.
My imports, admin.py. & views.py, are from .models.

I'm not sure what else you need to know. I look forward to helping expedite a resolution.

[Collin Anderson]

What is your ROOT_URLCONF set to and how are you referencing your views in your urls.py? How are you referencing your apps in INSTALLED_APPS? Does manage.py live in Baillee or next to Baillee?

[Malik A. Rumi]

ROOT_URLCONF = '%s.urls' % SITE_NAME
SITE_NAME = basename(DJANGO_ROOT)
DJANGO_ROOT = dirname(dirname(abspath(file)))

url(r'^{usconst/', include('usconst.urls')), [this is g:\Jasmine\Baillee\Baillee\urls.py]}

urlpatterns = patterns(,

url(r'^{usconst/$', apps.usconst.views.catland(template_name='statute.html')),
url(r'}usconst/Article\s\d[1-5]|[I-V]', apps.usconst.views.TOC(template_name='statute.html')),
url(r'^{usconst/Article\s\d[1-5]\s\Section\d[1-5]', apps.usconst.views.sectionView(template_name='statute.html')),
url(r'}usconst/(?P<slug>)', apps.usconst.views.sectionView(template_name='statute.html')),

[this is G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py - I noticed a missing ' in the regex and fixed it but still got the conflicting names error]

LOCAL_APPS = (

'apps.usconst.apps.UsconstConfig',

INSTALLED_APPS = DJANGO_APPS + THIRD_PARTY_APPS + LOCAL_APPS

G:\Jasmine\Baillee\manage.py

[Collin Anderson]

You either need to move your apps folder next manage.py or reference things as Baillee.apps.usconst instead of apps.usconst. Always reference absolute import paths relative to manage.py

[Malik A. Rumi]

Replying to collinanderson:

You either need to move your apps folder next manage.py or reference things as Baillee.apps.usconst instead of apps.usconst. Always reference absolute import paths relative to manage.py

-
I chose to go to absolute paths instead of moving apps, and that cleared up the conflict problem, so thanks. However, now I am getting a NameError - 'Baillee' is not defined - in my usconst/urls.py, which is importing * from views which in turn imports from models. I changed the * to specify the views but that made no difference. My understanding is that this error comes up because it is the first time Django/Python has seen a term and does not know what it is/means/represents. But if the checks are run in models and views before urls, why is this happening? I know this is not supposed to be a support forum, but I've been looking since yesterday with no luck. Any suggestions?

[Collin Anderson]

Would you be willing to post a traceback?

[Malik A. Rumi]

Replying to collinanderson:

Would you be willing to post a traceback?

I'd be willing to do just about anything... thx.

<> Note the typo 'shall' instead of 'shell' makes no difference -

(Sydney) G:\Jasmine\Baillee>python manage.py shall
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 385, in execute_from_command_line
    utility.execute()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 354, in execute
    django.setup()
  File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21, in set
up
    apps.populate(settings.INSTALLED_APPS)
  File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line 112,
in populate
    app_config.ready()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line 15, in
ready
    dt_settings.patch_all()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 215
, in patch_all
    patch_root_urlconf()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 203
, in patch_root_urlconf
    reverse('djdt:render_panel')
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 5
13, in reverse
    app_list = resolver.app_dict[ns]
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
29, in app_dict
    self._populate()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 2
69, in _populate
    for pattern in reversed(self.url_patterns):
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
67, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
61, in urlconf_module
    self._urlconf_module = import_module(self.urlconf_name)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
    url(r'^usconst/', include('Baillee.apps.usconst.urls')),
  File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py", line
28, in include
    urlconf_module = import_module(urlconf_module)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in <module>
    url(r'^usconst/$', Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined

<>
Typo corrected -

(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 385, in execute_from_command_line
    utility.execute()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 354, in execute
    django.setup()
  File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21, in set
up
    apps.populate(settings.INSTALLED_APPS)
  File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line 112,
in populate
    app_config.ready()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line 15, in
ready
    dt_settings.patch_all()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 215
, in patch_all
    patch_root_urlconf()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 203
, in patch_root_urlconf
    reverse('djdt:render_panel')
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 5
13, in reverse
    app_list = resolver.app_dict[ns]
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
29, in app_dict
    self._populate()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 2
69, in _populate
    for pattern in reversed(self.url_patterns):
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
67, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
61, in urlconf_module
    self._urlconf_module = import_module(self.urlconf_name)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
    url(r'^usconst/', include('Baillee.apps.usconst.urls')),
  File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py", line
28, in include
    urlconf_module = import_module(urlconf_module)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in <module>
    url(r'^usconst/$', Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined

<>
This is with 'Baillee.apps.usconst.views' commented out of the import line in usconst/urls.py -

(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 385, in execute_from_command_line
    utility.execute()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 354, in execute
    django.setup()
  File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21, in set
up
    apps.populate(settings.INSTALLED_APPS)
  File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line 112,
in populate
    app_config.ready()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line 15, in
ready
    dt_settings.patch_all()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 215
, in patch_all
    patch_root_urlconf()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 203
, in patch_root_urlconf
    reverse('djdt:render_panel')
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 5
13, in reverse
    app_list = resolver.app_dict[ns]
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
29, in app_dict
    self._populate()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 2
69, in _populate
    for pattern in reversed(self.url_patterns):
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
67, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
61, in urlconf_module
    self._urlconf_module = import_module(self.urlconf_name)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
    url(r'^usconst/', include('Baillee.apps.usconst.urls')),
  File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py", line
28, in include
    urlconf_module = import_module(urlconf_module)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in <module>
    url(r'^usconst/$', Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined

<>
This is with 'Baillee.apps.usconst.views' commented out of the import line in urls.py - 

(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 385, in execute_from_command_line
    utility.execute()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\management\__init__.py",
 line 354, in execute
    django.setup()
  File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21, in set
up
    apps.populate(settings.INSTALLED_APPS)
  File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line 112,
in populate
    app_config.ready()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line 15, in
ready
    dt_settings.patch_all()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 215
, in patch_all
    patch_root_urlconf()
  File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py", line 203
, in patch_root_urlconf
    reverse('djdt:render_panel')
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 5
13, in reverse
    app_list = resolver.app_dict[ns]
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
29, in app_dict
    self._populate()
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 2
69, in _populate
    for pattern in reversed(self.url_patterns):
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
67, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py", line 3
61, in urlconf_module
    self._urlconf_module = import_module(self.urlconf_name)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
    url(r'^usconst/', include('Baillee.apps.usconst.urls')),
  File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py", line
28, in include
    urlconf_module = import_module(urlconf_module)
  File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
  File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in <module>
    url(r'^usconst/$', Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined

(Sydney) G:\Jasmine\Baillee>

urls.py -

from django.conf.urls import patterns, include, url
from jinja2 import Template
from django.views.generic import TemplateView
#from Baillee.apps.usconst.views import *
#why don't i need to import re here?

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    url(r'^$', TemplateView.as_view(template_name='home.html')),

    # Examples:
    url(r'^$', TemplateView.as_view(template_name='home.html')),
    url(r'^404', TemplateView.as_view(template_name='404.html')),
    url(r'^500', TemplateView.as_view(template_name='500.html')),
    url(r'^about', TemplateView.as_view(template_name='about.html')),
    url(r'^contact', TemplateView.as_view(template_name='contact.html')),
    url(r'^survey', TemplateView.as_view(template_name='survey.html')),
    url(r'^join', TemplateView.as_view(template_name='join.html')),
    url(r'^pre-sale', TemplateView.as_view(template_name='pre-sale.html')),
    url(r'^library', TemplateView.as_view(template_name='library.html')),
    url(r'^testnumbers', TemplateView.as_view(template_name='testnumbers.html')),
    url(r'^usconst/', include('Baillee.apps.usconst.urls')),
    #url(r'^ussct/', include('ussct.urls')),
    # url(r'^Baillee/', include('Baillee.foo.urls')),
    # Uncomment the admin/doc line below to enable admin documentation:
    url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # Uncomment the next line to enable the admin:
    url(r'^admin/', include(admin.site.urls)),
)

usconst/urls.py -

from django.conf.urls import patterns, include, url
from Baillee.apps.usconst.views import catland, TOC, sectionView
#do i still need these imports if they are in project urls?

urlpatterns = patterns('Baillee.apps.usconst.views',
    url(r'^usconst/$', Baillee.apps.usconst.views.catland(template_name='statute.html')),
    url(r'^usconst/Article\s\d[1-5]|[I-V]', Baillee.apps.usconst.views.TOC(template_name='statute.html')),
    url(r'^usconst/Article\s\d[1-5]\s\Section\d[1-5]', Baillee.apps.usconst.views.sectionView(template_name='statute.html')),
    url(r'^usconst/(?P<slug>)', Baillee.apps.usconst.views.sectionView(template_name='statute.html')),
)

[Collin Anderson]

You have a few different options. I'd recommend this for Baillee/apps/usconst/urls.py :

from django.conf.urls import patterns, include, url
from Baillee.apps.usconst import views

urlpatterns = patterns('',
    url(r'^usconst/$', views.catland(template_name='statute.html')),
    url(r'^usconst/Article\s\d[1-5]|[I-V]', views.TOC(template_name='statute.html')),
    url(r'^usconst/Article\s\d[1-5]\s\Section\d[1-5]', views.sectionView(template_name='statute.html')),
    url(r'^usconst/(?P<slug>)', views.sectionView(template_name='statute.html')),
)

[Malik A. Rumi]

YES!!!
I had one more error, but I knew how to fix that, and I am in the shell! Huzzah! Thank you VERY much!

[Collin Anderson]

You're welcome. Way to go! I'll close this ticket.

If you or anyone else runs into this issue, and are still stuck after reading through the suggestions above, feel free to post the issue on the django-users group, or IRC.

If anyone can think of way to improve the documentation or error message feel free to re-open.

[Sergey Pashinin]

This bug breaks IPython autoreloading feature. Modules can not be updated with this error:

[autoreload of db.models failed: Traceback (most recent call last):
  File "/pyenvs/p3/lib/python3.4/site-packages/IPython/extensions/autoreload.py", line 247, in check
    superreload(m, reload, self.old_objects)
RuntimeError: Conflicting 'language' models in application 'db': <class 'db.models.Language'> and <class 'db.models.Language'>.

Used "./manage.py shell" which drops me into IPython.
When imported paths are different - this bug can be fixed.
But here we have reloading of absolutely the same file (and path)

Can this error be hidden (at least while settings.DEBUG==True)? Any way to throw it out?
It just breaks things.

[Sergey Pashinin]

Found a commit: ​https://github.com/django/django/commit/aff57793b46e108c6e48d5ce3b889bf90b513df9#diff-e0a696d19bf764562a439d3080a30fda

[Collin Anderson]

Interesting. Actually, that's a slightly different issue, because those have the _same_ path. Could you open a new ticket for that? and re-close this one?

[Carl Meyer]

Re-closing as the issue raised by @pashinin (supporting module reloading) is really a different issue (despite causing the same error message). Please file a new ticket for that and we can discuss it there.

[Tim Graham]

The new ticket for the above issue is #23621.