> Another thing to possibly consider, what should happen if multiple > packages try to provide different defaults for the same setting? I > mean, of course, this has kind of been floated in this thread already, > but it would add one more item to the list of things affected by the > order of INSTALLED_APPS.
Thus, why Adam called this a Hard Problem(tm). To resolve this, there would need to be a way for an app in INSTALLED_APPS to declare that it depends on another app. Then, despite the order in INSTALLED_APPS, the ready call could be re-ordered, or rather a new call could be introduced so that the dependent app could be informed once its parent has been initialized. The app could also be called before its "parents" are readied, so that it can tell what the user gave in settings. Maybe None is the default for a setting in the parent package, but 'lower' is to be the default setting in the dependent app... I am not asserting that such a feature is worth it, just shooting the S**T. On Wed, May 8, 2019 at 7:38 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > > On 8 May 2019, at 11:38, Michal Petrucha <mic...@petrucha.eu> wrote: > > > > On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote: > >> If we're only talking about providing default values for settings, > currently there are two straightforward solutions: > >> > >> 1. Like Adam suggested, access settings like this: getattr(settings, > 'MY_SETTING', 'my_default'). > >> > >> This works well when you access settings just once, probably at import > time, and cache their value. > >> > >> Here's an example: > https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34 > < > https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/backends.py#L27-L34 > > > > > > This approach, however, makes it impossible to use the decorators and > > context managers from django.test that override settings. Of course, > > there are other ways to tune those knobs in tests, but it takes away a > > standard solution provided by the framework. > > I'm not sure I understand what you're referring to. The framework provides > the setting_changed signal, which seems to work well here: > https://github.com/aaugustin/django-sesame/blob/070cdb3fcdfa6c7310d7461add328a8095148ff1/sesame/test_signals.py#L8-L18 > > >> DRF relies on a single Django setting which is a dict containing all > individual DRF settings. Then it converts that Django setting to an object > and uses this abstraction to access individual settings as properties. > > > > This seems to have become one of the current best practices, but it > > requires each reusable package that goes down this road to include a > > bunch of boilerplate just to deal with default values for settings. I > > suppose that boilerplate could be factored out into its own reusable > > package, but my gut tells me that there must be a better way to handle > > something as fundamental as providing defaults for settings. > > Definitely a very subjective claim, but I just feel like this is > > something that should be the responsibility of the framework itself. > > I'm ambivalent about this. I did it myself (TEMPLATES). I'm not sure that > was worth doing. > > Grouping a bunch of related settings in a dict looks satisfying. However, > it's less practical than giving them a common prefix, notably to override > them in tests. > > I suppose I could support a well-written proposal, though :-) > > >> Here we're talking about something slightly different: formalizing how > an application can declare default values for its own settings — > essentially a per-app equivalent of Django's global_settings.py. To do this > properly, we need two things: > >> > >> - a good convention for declaring these settings: I would find it > elegant to consider every uppercase class attribute of an AppConfig class > as a setting, but that might be too magic (and perhaps > backwards-incompatible); > > > > I definitely agree that this feels too magic-y. Maybe introducing a > > class attribute such as “DEFAULT_SETTINGS” that would hold a > > dictionary could work, though? > > Yes, it could work too. I considered it and didn't choose it because it > increases the distance between what global_settings.py looks like and what > app settings would look like. Not a very strong argument ;-) > > Also there's already magic to include only uppercase variables currently: > https://github.com/django/django/blob/ef9f2eb69c9396683cefa742bc7d0a0792090e8d/django/conf/__init__.py#L135-L137 > > >> - a way to insert them properly into the settings object: I tried to > figure out how LazySettings and friends handle global_settings, > unfortunately there are more use cases than I was willing to untangle > tonight. > > > > Another thing to possibly consider, what should happen if multiple > > packages try to provide different defaults for the same setting? I > > mean, of course, this has kind of been floated in this thread already, > > but it would add one more item to the list of things affected by the > > order of INSTALLED_APPS. > > Yes. Since the semantic is "make this value the default if there isn't a > value already" (i.e. setdefault), the most intuitive behavior should be > "first app in INSTALLED_APPS wins". > > Best regards, > > -- > Aymeric. > > -- > 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/20D907CE-D92E-4EF5-8EF4-8AF87F646017%40polytechnique.org > . > 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/CAFzonYZA4MQWn04_eGq66Z4Y3snHp2%3DnQgQocDYTG6Pxgv4b6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
