defining default settings for apps

[django@…]

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

The patch hooks in after the installed_apps got deglobed and sets the default value from default_settings.py 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.https://code.djangoproject.com/ticket/27798

[django@…]

implements app.default_settings as suggested

[Jacob]

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

[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 'settings.py' 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.

[Nebojsa Djordjevic <nesh at studioquattro dot co dot yu>]

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

try:
    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.

[limodou@…]

+1 for me too.

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

[django@…]

I like the idea of settings.app, 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.

[Adrian Holovaty]

Milestone Version 0.92 deleted

[django@…]

Updated version of old patch

[django@…]

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 default_settings.py 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.

[Shai Berger]

helper module for defining application settings objects

[Shai Berger]

Hi,

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 conf.py file looking like so:

import appsettings as appset

class Settings(appset.AppSettings):

    # A setting with a default given directly
    MY_SETTING_WITH_DEFAULT = 17
    
    # A setting which defaults to some other setting
    MY_SETTING_DEFAULTS_TO_OTHER = appset.FromSetting('ROOT_URLCONF')

    # Defaults can use settings from this file, too
    MY_SETTING_DEFAULTS_TO_LOCAL = appset.FromSetting('MY_SETTING_WITH_DEFAULT')
    
    # 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

[Jacob]

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

[Shai Berger]

Sorry, will do.

Thanks for your patience,

Shai.

[Anthony King]

Didn't know this existed when posting my feature request.
Ticket: https://code.djangoproject.com/ticket/27798
mailing list: ​https://groups.google.com/forum/#!topic/django-developers/JOO1bUJ10-U

Will carry on further discussions on the mailing list