standardised approach for packaged apps to define default settings

[Anthony King]

Yesterday, I posted a new ticket asking about the potential for adding a standardised approach for packages to define default settings. [0]

I was writing an app, and when looking for a way to set settings, there was no clear solution.

Looking at what other projects do, the goto was something like this:

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

This would then be accessed via myapp.settings, which will not reflect dynamic updates (specifically, override_settings).

What I feel is needed is this:

  - have apps access their settings via django.conf.settings, always

  - Allow to define default settings as cleanly as it is for settings to be written for projects.

  - Allow for dynamic settings that are calculated by default, but can be overridden by the project. [1]

  - Nice to have: This should ideally be written as a DEP so that it's usable on Django 1.11

These are by no means final solutions. I'm just looking to get the ball rolling.

I'd like to propose a couple of solutions for this to discuss.

- First, Load default_settings.py during the setup sequence.

I'm not sure how feasible this would be. What order would the settings app loads? what happens if your setting depends on another setting?

- Second, This could be done in AppConfig.

This introduces a fundamental new way of doing settings, and looks magical when using it.

class MyAppConfig(AppConfig):

    ...

    class DefaultSettings:

        MYAPP_SOME_SETTINGS = 'default'

        @property

        def MYAPP_DYNAMIC_SETTING(self):

            # set a default dynamically, based on environment or settings?

accessing settings.MYAPP_SOME_SETTINGS feels kind of strange though, as there's no direct relation between this new class and the django.conf.settings.

[0] https://code.djangoproject.com/ticket/27798

[1] https://github.com/YPlan/nexus/blob/620efbb7d13100848346c45717ca63d01ec301e5/nexus/conf.py

[Shai Berger]

Hi Anthony,

Two points:

1) 1.11 is feature frozen, nothing like a new subframework is likely to be
accepted to it.

2) The ticket is actually a dupe of an ancient ticket[1]. In that ticket, you
can see my own take of the subject, of several years ago.

In the years since then, I haven't felt an urgent need to try to revisit that
wontfix decision; but then again, I haven't written all that many reusable
apps.

HTH,
Shai.


[1] https://code.djangoproject.com/ticket/1371

[Raphaël Barrois]

Hello,

On this topic, I'm using the excellent django-appconf library (https://pypi.python.org/pypi/django-appconf), which:
- Supports namespaced custom settings
- Handles default values natively

As far as I can tell, that solution is pretty efficient without requiring specific Django support ;)

On Wed, 1 Feb 2017 01:29:12 -0800 (PST)
Anthony King <anthon...@gmail.com> wrote:

> Yesterday, I posted a new ticket asking about the potential for adding a
> standardised approach for packages to define default settings. [0]
>
> I was writing an app, and when looking for a way to set settings, there was
> no clear solution.
>
>
> Looking at what other projects do, the goto was something like this:
> #myapp/settings.py
> from django.conf import settings
> MYAPP_SOME_SETTING = getattr(settings, 'MYAPP_SOME_SETTING', 'default')
>
> This would then be accessed via myapp.settings, which will not reflect
> dynamic updates (specifically, override_settings).
>
>
> What I feel is needed is this:
> - have apps access their settings via django.conf.settings, always
> - Allow to define default settings as cleanly as it is for settings to be
> written for projects.
> - Allow for dynamic settings that are calculated by default, but can be
> overridden by the project. [1]

> - *Nice to have: *This should ideally be written as a DEP so that it's
> usable on Django 1.11
>
>
> *These are by no means final solutions. *I'm just looking to get the ball