Opened 6 years ago

Closed 5 years ago

#14720 closed Cleanup/optimization (fixed)

Settings imported twice as separate modules when manage.py is used

Reported by: Piotr Czachur Owned by: Brett Haydon
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

Description

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

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

Simple solution is to replace

    import settings # Assumed to be in the same directory.

with

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

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

Change History (5)

comment:1 Changed 6 years ago by mariarchi

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

comment:2 Changed 6 years ago by Brett Haydon

Owner: changed from nobody to Brett Haydon
Status: newassigned
Triage Stage: UnreviewedSomeday/Maybe
Version: 1.2SVN

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:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

comment:3 Changed 6 years ago by James Addison

Severity: Normal
Type: Cleanup/optimization

comment:4 Changed 5 years ago by Claude Paroz

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 5 years ago by Carl Meyer

Resolution: fixed
Status: assignedclosed

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