Hi all, thanks for your fast response - it seems that this is not a "ah, forget it, boooring." theme. I'll try to answer all (for me) relevant things at once here - sorry to write such a huge mail.
*@Adam Johnson:* > * 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. This is a good approach too, but it's not namespaced automatically. And app settings can't provide and override settings from other apps. This seems a weird suggest, but when apps depend on another app it should be able to override settings for that dependency too (because it "uses" that app anyway). > 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. Yes, this basically means namespacing. Depending on the size of the library, this could be one big bunch of a setting. > I think this pattern solves your first concern Christian. No it doesn't completely. I used this pattern myself in GDAPS, copied from graphene (which copied from DRF). But this does _not_ solve the problem: This pattern creates a per-app settings object which checks at the time of using (which is anywhere after main settings.py) if there is a global override of the local app's variable - and takes the right one. In this way it works. but this is not very convenient - you always have to ask the right settings object - it maybe would be more convenient, simpler and easier to code to just ask for a namespaced setting, e.g. in a dotted path style. like settings("django.ROOT_URLCONF") or settings("foo_app.SETTINGA") This is not a really good approach as it implements strings. > 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. Perfect. *@Matthew Pava* I have worked with Drupal for a long time before Django, and am maintaining a few sites with Drupal, one of it rather big, with many domains & shared content, 40+ modules, API to ther web services, some modules custom coded. I learned a lot of it, but PHP is really ugly. Django does much better, but, compared with Drupal, it has a few drawbacks. I know, Drupal is a CMS, Django is a framework (which you can build a CMS with) - BUT: Drupal is able (like Wordpress) to add modules/plugins per web download and on-the-fly - it installs modules into place, has a very good hooks system and a plugin manager. It also was a help when I designed GDAPS and was one of my blueprints. Drupal however keeps ALL of it's settings in the database which creates many problems on it's own (development/deployment problems how to sync settings from disk to database and vice versa). I wouldn't do that. Settings in code/conf files is a good thing IMHO. The package manager in Drupal is composer, yes, and together with GDAPS, you could use GDAPS Django packages exactly the sameway. Just install it using pip/pipenv, and Dajngo/GDAPS finds them automatically. But this can only be achieved by adding a line to settings.py (call the plugin manager), like I did: https://gdaps.readthedocs.io/en/latest/Installation.html#installation These are just hacks because Django doesn't have declarative settings. I suggest that if changing to declarative, it MUST be backwards compatible, yes. So there could be an _internal_ settings.py which loads environment variables, the bespoken config file, and like I said, **if** there is a settings.py in the project, Django could use it - to override settings in a way just code could do it. *@Jacob Rief and @Tom Forbes* Sure, JSON was just one idea. It's "xml 2.0", and not suited to be written by humans easily. yaml or toml would be better, in fact, in a first approach of GDAPS I used toml as meta config data for my Django plugins. I decided (because there IS no common framework in Django, and I didn't want to add another dependency) to let it go and am using an attribute of AppConfig ATM - code again. > /Some settings must be taken from the environment./* * Sure. DJANGO_SECRET_KEY etc. But this could be handled by the "internal" settings.py file. > /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./ _*Now that's the main point IMHO*__. _ I know Drupal a bit here, and They struggled until v7. You can read about "Configuration management" here: https://www.drupal.org/docs/8/configuration-management/managing-your-sites-configuration /By default, the "active" configuration is stored in the database ("config" table). This is for //performance and security reasons <https://www.drupal.org/node/2241059>//. This is the complete configuration for the entire site at that moment. Configuration can be exported and imported as YAML files, either in its entirety, or a single piece of configuration, using //*Drush *//and/or//*Drupal Console*//config commands or the //*Configuration Manager*//. (See below for more details.)/ Performance is a good reason here. getting settings from database is really fast. But I didn't like it. If I would design a settings backend, I would even make it pluggable... so that the user doesn't have to know there the settings come from. from django.conf import settings if settings.FOO.FOO_SETTING: pass the settings object could transparently check if any apps implement a "FOO" named object, and ask that object for "FOO_SETTING". This way the user always could ask the main settings object, but settings would be keeped namespaced. This is just like **i** would do it - again - just my 2 cents. BTW - and this is combined with it - Django IMHO needs a hooks system, like Drupal has. each point in code which needs "hooks" has it's own pattern of checking apps (search for modules, attributes in modules etc). Signals are not suitable enough and add complexity to the code structure. The GDAPS approach is an idea on how this "could" look like - even to use per-app settings: # Dream- and pseudo code (GDAPS integrated in Django ;-) ): # get interface for settings from Django (now GDAPS) from drupal.interfaces import ISettings for settings_object in ISettings: global_settings.merge(settings_object) So all plugins implementing ISettings are automatically found and can be merged in a way which needs to be done yet ;-) Yes, maybe I'm dreaming a bit. Dynamic app loading won't be applied any time soon in Django I suppose, btu settings could be done really better. If a can help in any way here, maybe even with code, please tell me. Have a Happy New Year everyone! Greetings from Salzburg, 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/06f4e659-70f2-cda1-a59e-35d7d79f3984%40nerdocs.at.
pEpkey.asc
Description: application/pgp-keys
