When using settings for my third party packages I use:
* A class to read django.conf.settings and add defaults/other logic through
properties - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/conf.py
. This has the benefit of easily providing defaults, complex logic such as
deriving one value from multiple settings, and being read from settings at
runtime rather than import time.
* A bunch of system checks to validate them - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/checks.py
. For example, if a setting is *required*, you can add a check error; or if
a setting defaults to something unsuitable for production, you can add a
deploy check. System checks make it easy for users to upgrade your package
too, since many users don't read changelogs even for breaking version
changes.
I am in favour of most libraries adding a single setting that controls
them, like DRF has REST_FRAMEWORK. I know django-cors-headers doesn't
implement the pattern but this is for legacy reasons since I took it over.
I think this pattern solves your first concern Christian. As for your
second concern, I think checks make manual installation of apps easier. If
a user adds your app to INSTALLED_APPS, the system checks will run and can
highlight any missing/misconfigured settings from following the
installation docs. Most libraries take 3 minutes to do the initial install
so I'm not sure of the value of automating that step compared to adding
system checks.
Jacob you're right it's a bit of an inconvenience to write a class to wrap
django.conf.settings but I'm not sure there's any general purpose wrapper
that could be provided. There are too many cases for evolution - a setting
changes name, one value combines multiple settings, etc.
On Tue, 31 Dec 2019 at 00:09, Tom Forbes <t...@tomforb.es> wrote:
> My two cents: JSON isn’t great as a configuration language - It’s
> annoyingly picky about some things. YAML or TOML are “better” (for some
> definition of better) choices for this domain, in my option. However,
> Django is historically quite hesitant about including third party packages
> and I think including a TOML or YAML parser even as an optional dependency
> might not be the way forward.
>
> So rather than just “allowing people to use JSON files for settings” it
> would be very interesting to explore what a pluggable settings backend
> would look like. It seems that work in this area would be best spent on a
> general abstraction rather than a specific one. There was some discussion
> around this idea in the GSOC thread and I’m sure it’s come up before.
> Personally I think configuration management is an area of Django that is
> quite underdeveloped compared to other frameworks.
>
> On 30 Dec 2019, at 22:46, Christian González <
> christian.gonza...@nerdocs.at> wrote:
>
> Hello,
>
> I recently "finished" my first really working version of GDAPS, my
> Generic Django Application Plugin System. It's noway perfect, but does
> what it should: providing pluggable apps for an app framework, including
> a more or less flexible frontend with each django app.
>
> I had much struggle with it, and one of the lessons I learned was
> Django's setup system, and how it deals with loading apps. Unfortunately
> Django can't load/unload apps on the fly, so it is necessary to restart
> Django whenever a new GDAPS app is installed via pip.
>
> But: I want to resurrect an old theme again which would, in a way,
> improve some of the loading problems I encountered. Django's settings
> are code. Which is, in fact, a very good thing, as it makes it extremely
> flexible and adaptable to different setups. But, as discussed with the
> SECRET_KEY here, some of the settings _have_ to be coded very
> complicated, and it makes some things like per-app-settings extremely
> uncomfortable.
>
> What if - and please don't kill me instantly - yes, I am a newcomer, and
> not a good programmer maybe - but some things are viewed better from
> "outside" - what if Django settings could be "declarative"?
>
> So instead of Python code like
>
> INSTALLED_APPS = [
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes'
> ]
>
> This would be in an e.g. JSON file
>
> {
>
> "INSTALLED_APPS": [
> "django.contrib.admin",
> "django.contrib.auth",
> "django.contrib.contenttypes"
> ] ,
> ROOT_URLCONF: "fooproject.urls"
> }
>
> Django's settings.py would look different: It would load that
> settings.json file and set the appropriate values into local code - so
> this wouldn't make much difference.
>
> Except 2 things:
>
> 1. Apps could have (default) settings, and they could be merged MUCH
> easier. Things like namespaced classes that are overwriting values like
> DRF/graphene does, would be completely unnecessary. The main
> settings.json file could be the "last word" in the process of settings,
> so anything an app would suggest could be overrided in the main file.
>
> 2. Installed apps could be managed much more comfortable. Adding an app
> could be done by a script (JSON editing is easy. Editing code
> (=settings.py) is error prone and uncomfortable). I have a Django
> command script ATM for that, but just because I add a line into
> settings.py to add some additional apps to the list.
>
> This even could be done with backwards compatibility, because Django
> would keep it's settings.py file optionally:
>
> * read json settings (if they exist), use them
> * load settings.py which allows to override them again (using some
> special code tricks like dynamic loading, environments etc.)
>
> Please tell me what you think about that.
>
> Christian
>
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3047a7b6-3fa0-d574-4bb6-7842b7aed44a%40nerdocs.at
> .
> <pEpkey.asc>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/D7000C61-69C0-4E59-9DB8-4BB1413B0C98%40tomforb.es
> <https://groups.google.com/d/msgid/django-developers/D7000C61-69C0-4E59-9DB8-4BB1413B0C98%40tomforb.es?utm_medium=email&utm_source=footer>
> .
>
--
Adam
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM3-pFQQYwraTPJYvC0SJqWZvFYi8jpPq%3D4Bianxoi5EDQ%40mail.gmail.com.
