Declarative settings, and a lack of a good settings file parsing system, led me into some rather interesting directions not that long ago.
I maintain an OpenStack project called Adjutant, and I built it on Django, but ended up using yaml as my config file and having settings.py read it and pull in certain values. But I ended up doing some rather weird nested stuff, and kept introducing small sections of code that needed some config value. But because I didn't have a way to declare those configs somewhere, it essentially turned into a nightmare to know exactly what values were configurable, and where in the code they were used. OpenStack uses a config library system called oslo.config which allows declaring config, and then consuming it. Sadly for me that didn't handle nesting. dynamic config registration... or too much weird complexity. Plus it was based off INI files, and didn't support yaml or toml. So I ended up writing my own variant which did. The library I wrote is: https://gitlab.com/catalyst-cloud/confspirator And the way I use it: https://github.com/openstack/adjutant/tree/master/adjutant/config https://github.com/openstack/adjutant/blob/master/adjutant/settings.py Which this being how I handle my plugins, and their config: https://github.com/openstack/adjutant/blob/master/adjutant/feature_set.py The whole thing is maybe a little over the top, but it allows dynamic config registration via plugins, declarative values, so you can't ever use a config without defining it, and it can read those config values from envvars or you can pass it a dict structure to parse (which you can load in from json, yaml, or toml). And a way to then use that config tree to generate example config: https://github.com/openstack/adjutant/blob/master/adjutant/commands/management/commands/exampleconfig.py This may not be what you need, but given my random pain in what I think is a similar area, I thought I may as well share. I do intent to maintain CONFspirator, and will be adding native support for parsing/loading yaml/toml, as well as utils for example config generation soon. On 31/12/19 11:45 am, Christian González 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 > > -- 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/c6e3a6db-e75d-8963-904f-f07e76614c13%40catalyst.net.nz.
