Am 02.01.20 um 08:06 schrieb Alexei Znamensky: > Having said that, I recently stumbled on this package > django-configurationsby chance, while working on something else. It > looks quite promising, as one can use (multiple) class inheritance to > merge and combine different settings. As far as I can tell, it lacks > the dynamic aspect of your GDAPS idea, so I suppose it would not solve > the problem of loading plugins in runtime. But, for the part in which > you want to load settings from json/yaml/toml/database/wherever, it > might be simpler to piggyback on that project and have Configuration > classes that load markup, and a config class that loads from DB > (although this would probably be trickier than it looks). yes, I already had stumbled upon django-configurations too. But apart from not solving the dynamic loading "problem" of Django (which is not my main concern: reloading the django server is ok for me ATM), it drags in a bunch of own config necessities and changes that have to be done to make it work: The "quick start" replaces the whole settings.py with a class, and you have to change the manage.py file too. No plug'n'play. Sure, you can make this class load a config file then too.
But for me it reminds me of the joke: Waiter: What would you like to eat? Guest: I'd like to have a burger with fries, but instead of the fries please bring me rice, and instead of the burger I'd like a soup. If I replace everything the config does, it can do something else. But it still does not solve my problem at all... which is easily *changing* the installed apps programmatically - so that, after a restart - new apps are available. In GDAPS, I only add one line, if you install GDAPS apps per pip, they are found automatically and work after a restart. But I think this is Django's "fault" - it could do better. What would be really a game changer: in django.conf there are LazySettings and Settings classes, and they currently load from a module (https://github.com/django/django/blob/c574bec0929cd2527268c96a492d25223a9fd576/django/conf/__init__.py#L171), after checking the ENVIRONMENT_VARIABLE. A quick proposal would be to 1. load the environment variable to get the settings name 2. NEW: look for a declarative settings file and load that 3. if that doesn't exist (or additionally), load the settings from project's settings.py as usual This way everything would be completely unchanged and backwards compatible, while adding declarative settings functionality. This doesn't solve per-app settings - but while loading the declarative config, installed apps would be defined already - and their paths should be possible to determine by then. So *their* declarative settings could be found and merged as well. 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/5c3f0bab-4d82-973c-140f-bc6254a52937%40nerdocs.at.
pEpkey.asc
Description: application/pgp-keys
