Code

Opened 8 years ago

Closed 5 years ago

Last modified 3 years ago

#1371 closed defect (wontfix)

defining default settings for apps

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

Description

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.

Attachments (3)

default_config.patch (844 bytes) - added by django@… 8 years ago.
implements app.default_settings as suggested
1371.diff (977 bytes) - added by django@… 6 years ago.
Updated version of old patch
appsettings.py (3.1 KB) - added by shai 5 years ago.
helper module for defining application settings objects

Download all attachments as: .zip

Change History (16)

Changed 8 years ago by django@…

implements app.default_settings as suggested

comment:1 Changed 8 years ago by jacob

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

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

comment:2 Changed 8 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 '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.

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 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 8 years ago by 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.

comment:6 Changed 8 years ago by adrian

  • milestone Version 0.92 deleted

Milestone Version 0.92 deleted

Changed 6 years ago by django@…

Updated version of old patch

comment:7 Changed 6 years ago by django@…

  • Summary changed from [patch] provide a standard way for new config variables in apps to defining default settings for apps
  • Version changed from magic-removal to SVN

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.

Changed 5 years ago by shai

helper module for defining application settings objects

comment:8 Changed 5 years ago by shai

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

comment:9 Changed 5 years ago by jacob

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

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

Sorry, will do.

Thanks for your patience,

Shai.

comment:11 Changed 5 years ago by guettli

  • Cc hv@… added

comment:12 Changed 5 years ago by gonz

  • Cc gonz added

comment:13 Changed 3 years ago by guettli

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.