Opened 8 years ago

Closed 8 years ago

#27798 closed New feature (duplicate)

Add a standardised approach for packaged apps to define default settings

Reported by: Anthony King Owned by: nobody
Component: Core (Other) Version:
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

WIP: I'm writing this up as I think about different aspects of it. If people like the general idea, I can redo it once my thoughts are consolidated.

Currently, people are making apps that use a variety of different ways to manage their settings.

A common way is this:

# myapp/settings.py
from django.conf import settings
MYAPP_SOME_SETTINGS = getattr(settings, 'MYAPP_SOME_SETTINGS', 'default')

However as mentioned by Adam, this can cause breakages in override_settings if this is done at import time.

Also mentioned by Adam is that default settings sometimes need to be backed by some form of logic. He currently uses this approach:
https://github.com/YPlan/nexus/blob/620efbb7d13100848346c45717ca63d01ec301e5/nexus/conf.py

I'd like to propose a change to django settings that will allow loading a default_settings.py from packaged apps as part of the setup sequence.

This has 2 advantages:

  • default_settings.py becomes less verbose/error prone
  • structures of packages becomes less fragmented

There is potential to clean up internal code as well (such as moving contrib settings out of global_settings.py)

Even though I keep referencing default_settings.py, it doesn't have to be this file. To avoid conflicts, the module could be set in AppConfig.

A second approach could also be to define default settings in the AppConfig itself..

# myapp/apps.py
class MyAppConfig(AppConfig):
    ...
    class DefaultSettings:
        MYAPP_SOME_SETTINGS = 'default'

        @property
        def MYAPP_DYNAMIC_SETTING(self):
            # set a default dynamically, based on environment or settings?

This approach would allow for Adam's dynamic default usecase.

Could someone who knows the setup order provide feedback on this?

Change History (2)

comment:1 by Tim Graham, 8 years ago

Component: PackagingCore (Other)
Triage Stage: UnreviewedSomeday/Maybe

As this involves some significant design decisions, it'll be better to discuss it on the DevelopersMailingList.

comment:2 by Shai Berger, 8 years ago

Resolution: duplicate
Status: newclosed

I believe this to be a dupe of #1371, which was closed wontfix in the dawn of history. You may want to direct the mailing-list discussion towards reopening it, or explain why things are so different now that things said there are no longer relevant (and reopen this ticket).

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