Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#8703 closed (fixed)

Development server fails to load settings

Reported by: benspaulding Owned by: nobody
Component: django-admin.py runserver Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (1)

envset.diff (615 bytes) - added by kmtracey 7 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by benspaulding

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 follow-up: Changed 7 years ago by kmtracey

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.

Changed 7 years ago by kmtracey

comment:3 in reply to: ↑ 2 Changed 7 years ago by kmtracey

  • milestone set to 1.0

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.

comment:4 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

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).

comment:5 Changed 7 years ago by kmtracey

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.

comment:6 Changed 7 years ago by tekNico

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:7 Changed 7 years ago by ramiro

  • Resolution fixed deleted
  • Status changed from closed to reopened

undo accidental closing

comment:8 Changed 7 years ago by tekNico

Ops, sorry. :-/

comment:9 Changed 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

(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.

comment:10 Changed 4 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top