Opened 5 years ago

Closed 4 years ago

#14720 closed Cleanup/optimization (fixed)

Settings imported twice as separate modules when is used

Reported by: zimnyx Owned by: bretth
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Some people may be surprised that settings are loaded twice under different names in sys.modules:

  • import 1) as 'settings' (, imported in same-dir fashion)
  • import 2) as "projectname.settings" (import_module() triggered when LazySettings is accessed first time; projectname/ is loaded)

Simple solution is to replace

    import settings # Assumed to be in the same directory.


    # Project module is known during creation, because it's django-admin startproject parameter.
    from project_module import settings

This change affects package/module loading order:
projecname/ will be executed during importing of settings inside

Change History (5)

comment:1 Changed 5 years ago by mariarchi

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

I was bitten by the current behavior as well, I agree that it is quite annoying.

comment:2 Changed 5 years ago by bretth

  • Owner changed from nobody to bretth
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Someday/Maybe
  • Version changed from 1.2 to SVN

Note: you cannot use 'from project_module import settings' unless you have explicitly added project_module to your PYTHONPATH

Graham Dumpleton has a good post on this:

comment:3 Changed 5 years ago by jaddison

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:4 Changed 4 years ago by claudep

  • Easy pickings unset
  • UI/UX unset

I suspect that this might be resolved now after changeset:16964. Just need someone confirmation to close the ticket.

comment:5 Changed 4 years ago by carljm

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

This was indeed fixed by r16964 - didn't realize there was a ticket open for it.

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