Change History (3)

When name conflict, the application can fail in multiple place (or not). It depends on what you do where, so we cannot help you unless we know exactly where the proper exception has been swallowed. Please try to debug and give us more details.

Ok, I figured out what happens:
Django tries to look up the database settings. Instead of <project>.settings it uses <app/module>.settings where it doesn't find database settings and so it raises the error.

To reproduce:
Remove any module from PYTHONPATH, start a Django project with the same name, configure it to use sqlite and run syncdb. Add the module again. Run syncdb. It raises the error. Copy the database settings into <app/module>.settings for testing and run syncdb. Now it's ok.

Before looking up settings or else inside the project it would be good to check if there is a name conflict.

It is not possible for Django to "check if there is a name conflict" without re-implementing large chunks of Python's import system. Django _already_ prevents you from creating a project with a package name that conflicts with some other package on sys.path; this is the most we can reasonably do. If you circumvent that by taking modules off PYTHONPATH and putting them back on later, Django has no way to know that there are two modules with a conflicting name on sys.path, because Python's import system doesn't provide any way to find that out. All we know is what we get back when we "import helpdesk", and we have to work with that as best we can.

Normally in this case you'd get a quite clear error that your DJANGO_SETTINGS_MODULE "helpdesk.settings" does not exist. It sounds like you have even more of an unusual edge case where the other module that is shadowing your project on sys.path _also_ has its own "settings" submodule. In this case, again, there is no way that Django can know that this settings module is not actually the one you are intending to use - so the error you get is the clearest one Django can give.