Scoped settings.

[tomchristie]

In REST framework we scope all the settings that the project uses inside a single dictionary.

For example...

REST_FRAMEWORK = {
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.JSONRenderer',
    ),
    'DEFAULT_PARSER_CLASSES': (
        'rest_framework.parsers.JSONParser',
    )
}

I wasn't sure about the decision at first, but I've been really pleased with it since. It forcibly ensures that all the settings are properly grouped in users settings modules, and nicely declutters everything.

Interested to know if you'd consider something similar if it came with a very gradual deprecation path.
For example, migrating towards this?...

WAGTAIL = {
    'SEARCH_BACKENDS': {...},
    'IMAGES_MAX_UPLOAD_SIZE': 50 * 1024 * 1024
}

Would you folks consider that better or worse, and would you you either:

• Consider it broadly a "no".
• Be interested in a pull request for further consideration/review/discussion.
• Something else.

Thanks all!

[MechanisM]

👍

[davecranwell]

We did consider this here: #723

[tomdyson]

@tomchristie this makes sense to me, especially when Wagtail is being used as part of another Django app. How would a gradual deprecation path work?

[tomchristie]

@tomdyson - Something like...

Internally have a wagtail_settings object. Access settings internally using:

from wagtail.wagtailcore.settings import wagtail_settings

wagtail_settings.SEARCH_BACKENDS

That'd end up checking for both styles (and probably cache the resulting looking, perhaps with eg path imports for some kinds of settings strings, such as the DEFAULT_RENDERER_CLASSES example above.)

In v1 either style would be acceptable.
In v2 having to fallback to the unscoped version would caused a PendingDeprecationError (which is only visible when warnings are explicitly turned on)
In v3 having to fallback to the unscoped version would caused a DeprecationError (which is always visible)
In v4 the old style is removed.

Related:

• Example of using the api_settings object in REST framework.
• The api_settings implementation.

[SalahAdDin]

👍

[thibaudcolas]

Since 2015 I’d imagine we’re pretty happy with the current "prefixing" approach, so I’ll convert this to Discussions. See #11368 for more discussions on settings management.