Development server fails to load settings

[Ben Spaulding]

Using django-admin.py runserver fails to load the settings if:

1. the settings module is three or more levels deep, and
2. you rely on DJANGO_SETTINGS_MODULE

Examples

I don’t know how to patch the problem, but this is the testing I did to see what all was affected.

Failures

Directory structure:

          django
        /
~/sites
        \
          mysite---foo---settings.py

Command line:

$ cd ~/sites
$ PYTHONPATH=pwd
$ DJANGO_SETTINGS_MODULE=mysite.foo.settings
$ django-admin.py runserver
Error: Could not import settings 'foo.settings' (Is it on sys.path? Does it have syntax errors?): No module named foo.settings

Directory structure:

          django
        /
~/sites
        \
          mysite---foo---bar---settings.py

Command line:

$ DJANGO_SETTINGS_MODULE=mysite.foo.bar.settings
$ django-admin.py runserver
Error: Could not import settings 'bar.settings' (Is it on sys.path? Does it have syntax errors?): No module named bar.settings

Success

I found no failure with manage.py. django-admin.py succeeded as long as the settings module was not nested more than two deep or was set explicity with the --settings option.

Directory structure:

            django
          /
~/sites---
          \
            mysite---settings.py

Command line:

$ DJANGO_SETTINGS_MODULE=mysite.settings
$ django-admin.py runserver
Validating models...
0 errors found

Django version 1.0-beta_2-SVN-8645, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Directory structure:

            django
          /
~/sites---
          \
            mysite---foo---settings.py

Command line:

$ django-admin.py runserver --settings=mysite.foo.settings
Validating models...
0 errors found

Django version 1.0-beta_2-SVN-8645, using settings 'mysite.foo.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

[Ben Spaulding]

I forgot to mention that there are __init__.py files in all the needed places and I can import the settings just fine from the python interpreter. The problem seems to be that Django is chopping off part of the module path, for example, foo.settings or bar.settings rather than mysite.foo.settings or mysite.foo.bar.settings, respectively.

[Karen Tracey]

Shortening of the environment variable is happening on this line:

os.environ['DJANGO_SETTINGS_MODULE'] = '%s.%s' % (project_name, settings_name)

of source:django/trunk/django/core/management/__init__.py in setup_environ(). So, first time settings are loaded all is OK, but subsequent times the environment variable has been shortened to the last two parts, and subsequent loads don't work. Why are settings loaded multiple times? I think they are loaded for each thread...at any rate specifying --noreload makes the problem go away. I'm not comfortable enough with the code involved here to even suggest a fix.

[Karen Tracey]

Replying to kmtracey:

I'm not comfortable enough with the code involved here to even suggest a fix.

Oh when have I let that stop me before? Attached a patch that avoids over-writing an existing os.environ[DJANGO_SETTINGS_MODULE]. Seems innocuous enough, assuming there isn't some deep-rooted assumption that settings is always of the form project.settings_module. Tagging 1.0 for someone with a clue to take a look and decide if this is a valid case worth fixing for 1.0.

[Malcolm Tredinnick]

So the problem with this patch, Karen, is that if you call django-admin.py --settings=foo (for appropriate value of "foo") and you have DJANGO_SETTINGS_MODULE set to something else, the settings used and the environment variable end up being different, because the latter doesn't get set appropriately. That will lead to very difficult to diagnose bugs down the track when something only reads the environment variable for some reason (I don't know what that would be, but when it happens, it will be very weird behaviour). We've tried hard to always keep the environment variable synchronised.

So we have to find a way to set it properly here. This looks like a bug, but the solution needs a different touch (and I'm not going to work out what that is right now, because it's nap time).

[Karen Tracey]

Yes, the patch will cause the environment variable to be out of sync with any specified --settings if both are used. I did check that the right one (--settings overrides environment, right?) would still be used in that case but I can see how you'd want them to be in sync. It's just the kind of detail users neglect to mention.

[Nicola Larosa]

(In [8767]) Fixes #8703 - Italian translation: updated django.mo, just for
completeness, no string changes.

[Ramiro Morales]

undo accidental closing

[Nicola Larosa]

Ops, sorry. :-/

[Malcolm Tredinnick]

(In [8768]) Fixed #8703 -- Allow deeply nested import paths for DJANGO_SETTINGS_MODULE when
running django-admin.py. Also adds a parameter to setup_environ() for others to
use as well.

[Jacob]

Milestone 1.0 deleted