Long time lurker first time poster; could this possibly be addressed with something along the lines of SECRET_KEY? It seems to me that no more of a namespace would be needed than a uniquely identifying hash per app/module. Not so much in settings or app_config as __init__, maybe?
Hi, Benny > On Jun 16, 2019, at 7:18 PM, Curtis Maloney <cur...@tinbrain.net> wrote: > > [forgive me for typing as I think... but sometimes it's the best way to think > ;) ] > >> On 6/17/19 5:19 AM, Christian González wrote: >>> Am 16.06.19 um 10:06 schrieb Adam Johnson: >>> * What do you think are the implications for Django core? Is there anything >>> Django could do better to support this and all the other plugin systems >>> you’ve looked at? Also I’m totally sure you can contribute, it’s not scary >>> and there is a lot of information on getting started! See >>> https://docs.djangoproject.com/en/dev/internals/contributing/ >> Yes, I'll have a deeper look at the contributing guidelines. >> The most parts where I had to struggle within Django were: >> * The settings, to let each module provide it's own setting. There is no >> standardized way of having settings saved. I borrowed the graphene-django >> way - which had copied it from DRF ;-) > > I've given some thought to this over the years, and what I think we've > somehow missed in settings until now is ... Namespaces! > > Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict (DATABASES > = {} ) when it comes to plugins having their own declared settings, we may > want to move to something a little more formal. > > Any plugin or app ought be able to declare its own settings and their > defaults. And ISTM the "obvious" place to do this is in their AppConfig > > Except, that may be too late, since we may want/need the settings before apps > are loaded? > > So the alternative is for a plugin to declare in its entry points a reference > to its settings declaration. This way, all 3rd party settings can be > gathered, vetted, and applied before having to scan the INSTALLED_APPS list. > > Now what we'll need is a way to avoid namespace clashes, and a dev-friendly > way to update these settings in settings.py > > -- > Curtis > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/67996E66-F881-467A-970B-24B93D7DCE83%40twosensedesign.com. For more options, visit https://groups.google.com/d/optout.
