Opened 14 years ago

Closed 11 years ago

Last modified 3 years ago

#1371 closed defect (wontfix)

defining default settings for apps

Reported by: django@… Owned by: Adrian Holovaty
Component: Core (Other) Version: master
Severity: normal Keywords:
Cc: Gonzalo Saavedra Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Anthony King)

I think django should have a simple and easy way for setting new variables in apps.
I suggest that a app/someapp/ file would be imported when it exists and be handled like the

The patch hooks in after the installed_apps got deglobed and sets the default value from if it doesn't exist already in the user conf.
This way, adding new variables is very easy and uniform and apps can use the standard way without much checking for existence of keys.

Attachments (3)

default_config.patch (844 bytes) - added by django@… 14 years ago.
implements app.default_settings as suggested
1371.diff (977 bytes) - added by django@… 11 years ago.
Updated version of old patch (3.1 KB) - added by Shai Berger 11 years ago.
helper module for defining application settings objects

Download all attachments as: .zip

Change History (17)

Changed 14 years ago by django@…

Attachment: default_config.patch added

implements app.default_settings as suggested

comment:1 Changed 14 years ago by Jacob

Resolution: wontfix
Status: newclosed

This feels crufty. Just document the settings your app needs and raise exceptions if it doesn't find 'em.

comment:2 Changed 14 years ago by django@…

I think this is an important problem. I don't want to copy and paste settings every time I add an application. With Django's global settings it's great being able to plug and play then gradually tweak as you become familiar with the customisation options. I think the basic idea of having a '' file in the application directory that gets automatically incorporated is good. Either there would need to be a convention to prefix settings names with the application name or else application-specific settings should get their own namespace. I think the former would be ok.

comment:3 Changed 14 years ago by Nebojsa Djordjevic <nesh at studioquattro dot co dot yu>

+1 from me, for now in my apps I'm using

    from django.conf.settings import VAR
except ImportError:
    VAR = <somedefault>

with m-r branch it is probably like this:

from django.conf import settings
VAR = getattr(settings, 'VAR', <somedefault>)

Still it will be great (in m-r) now when settings is a object that all apps can have dedicated namespace for settings like settings.<app>.FOO, this will greatly prevent name clashes.

comment:4 Changed 14 years ago by limodou@…

+1 for me too.

I think this will simplify the app configuration. App can hold urlsconf why not settings?

comment:5 Changed 14 years ago by django@…

I like the idea of, but I think the current solution is adequat.
Simply call your variables [APPNAME]_SOMETHING, this would prevent nameclashes without much overhead.
However, a simple stadard way that is uniform looks and feels a lot better then then the current way in my opinion.

comment:6 Changed 13 years ago by Adrian Holovaty

milestone: Version 0.92

Milestone Version 0.92 deleted

Changed 11 years ago by django@…

Attachment: 1371.diff added

Updated version of old patch

comment:7 Changed 11 years ago by django@…

Summary: [patch] provide a standard way for new config variables in appsdefining default settings for apps
Version: magic-removalSVN

Resurrecting a very old idea.

With this change, an application can be distributed and allow site developers to customise the app's behaviour. Apps can already do this non-trivially, but declaring the settings in the app's is cleaner. A site developer can find relevant settings for an app in a single, easy to discover file.

Contrib apps like admin get to define their default settings in this way, why not normal apps?

Possible problems:

  • REQUIRED SETTINGS should not have defaults, so that an exception will be thrown. Application developers might be tempted to give them default values in a default_settings module.
  • REGISTRATION: A better approach would be to allow application developers to name their module however they like, and register it. The change for this approach is no longer trivial.
  • BACKWARDS COMPATIBLITY: This will cause problems for existing apps that for some reason have a default_settings module (with uppercase variables) that is not supposed to provide default settings for django. This is unlikely, but possible.
  • NAMESPACES are not used here, application developers can (and should) use the naming convention of APPNAME_SETTINGNAME, but if they don't they might cause headaches. This approach also adds another barrier to any future attempt to allow applications to have the same app_name.

Changed 11 years ago by Shai Berger

Attachment: added

helper module for defining application settings objects

comment:8 Changed 11 years ago by Shai Berger

Resolution: wontfix
Status: closedreopened


This bug has been fairly active for one marked closed/wontfix, so I suspect the closing was a little premature. Further, very similar bugs were opened again, #5049 and #7015; they were closed as wontfix and dupe, respectively. The closing of #5049 refers to past discussions which I could not find (I searched the users and developers google groups for "application settings" in various spellings), and I'd be thankful if anyone could either point to the relevant messages or repeat the arguments here.

Anyway, I was able to find some (later) discussions in this google search. In them, the main objection to this feature is that it lets apps include their own settings in the global settings object, and I tend to agree with that sentiment. However, I still think it is much nicer for the application settings to be concentrated in one place. This would help not only deployers, but also developers who will be able to rely on IDE services (intellisense, refactoring) for their own settings.

My idea for not messing with the global settings object, is for each app to have its own settings object, which serves as a proxy to the global settings object. The global settings object remains un-tainted. With the appsettings module I attached here, the application would include a file looking like so:

import appsettings as appset

class Settings(appset.AppSettings):

    # A setting with a default given directly
    # A setting which defaults to some other setting

    # Defaults can use settings from this file, too
    # Defaults can be computed, and not just copied from other settings
    MY_SETTING_WITH_COMPUTED_DEFAULT = appset.ComputedSetting(lambda x,y,z=0:x*y+z, ['MY_SETTING_WITH_DEFAULT'], 3, z=17)
    # This must be set in the settings module
    MY_TOP_SETTING = appset.RequiredSetting()
settings = Settings()

And the app should then just replace its "from django.conf import settings" with "from myapp.conf import settings".

This addresses all concerns raised before, that I am aware of:

  • Applications cannot touch each-other's defaults (unless some app explicitly imports another's settings)
  • Required settings can be clearly marked as such
    • When so marked, if not defined in the settings module, their use in the code will predictably raise ImproperlyConfigured, instead of each app raising its own error
  • No registration required
  • No backwards compatibility issues, just a way to make things better in the future
  • No default clashes even if name clashes occur (each app can have its own default for the same name) -- so the setting-name-clash situation is not worsened.
  • No more RY "if hasattr(settings,'...')". Just use the setting value in your code.
  • The FromSetting and ComputedSetting classes are further RY-removing convenience features

comment:9 Changed 11 years ago by Jacob

Resolution: wontfix
Status: reopenedclosed

Please don't reopen tickets closed by a committer. The correct way to revisit issues is to take it up on django-dev.

comment:10 Changed 11 years ago by Shai Berger

Sorry, will do.

Thanks for your patience,


comment:11 Changed 11 years ago by Thomas Güttler

Cc: hv@… added

comment:12 Changed 11 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra added

comment:13 Changed 8 years ago by Thomas Güttler

Cc: hv@… removed
Easy pickings: unset
UI/UX: unset

comment:14 Changed 3 years ago by Anthony King

Description: modified (diff)

Didn't know this existed when posting my feature request.
mailing list:!topic/django-developers/JOO1bUJ10-U

Will carry on further discussions on the mailing list

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