I myself am using an implementation like DRF does it:
They create a class "APISettings", and
mimic the Django behaviour.
Dand graphene-django has adapted it already and changed a bit:
Mind the "# Copied shamelessly from Django REST Framework" ;-)
And yes, I shamelessly copied it too in my GDAPS project.
But it's a really bad workaround, and does not function like I would "phthonically" like it.
Christian
Great idea Christian, actually some frameworks have this kind of feature, such as CakePHP, in which apps can also inject urls and middlewares for example.
This would be a huge step forward for the ecosystem (and when apps can share node modules you're done haha !).
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAC6Op1-31f1bimWFsWG9PA8oqu1rRErurkUFnXr6%3D8FyrWfEYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Great idea Christian, actually some frameworks have this kind of feature, such as CakePHP, in which apps can also inject urls and middlewares for example.This would be a huge step forward for the ecosystem (and when apps can share node modules you're done haha !).
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAC6Op1-31f1bimWFsWG9PA8oqu1rRErurkUFnXr6%3D8FyrWfEYg%40mail.gmail.com.
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/11e20db3-fc69-c6a9-750c-4edfb86fcc44%40nerdocs.at.
Hi Americ,
thanks for answering THAT elaborative (I first thought that it#s a typical newbie question).
When you say this is not possible, I assume you are referring to my work on app-loading in Django 1.7. Here's what comes to mind.
[...]
Finally, this would mean that pluggable apps cannot assume that settings are immutable anymore. It would become a best practice for every pluggable app to assume that any setting can change and to deal with the consequences. I'm not enthusiastic at the prospect of adding this overhead to the ecosystem.
Yes and no. I wrapped my head around the chicken-egg-problem for many weeks now.
I think that immutable settings are a good thing at last, and I would never suppose to change that. settings.py is thought to be run *once*, at server start. Or at least at reload. But then, apps are reloaded too.
What I think of is something else, maybe I didn't explain it good enough:
Apps should have the possibility to add DEFAULT settings to the Django global settings. As already mentioned in my plugin system question, I don't see a problem with app/settings loading order. The loading order is done in INSTALLED_APPS, immutable, and good as it is.
App A could e.g. have a WEBPACK_LOADER variable that is imported into the global scope, and the settings.py then CAN override it.
It's that Django's settings.py SHOULD remain the master of settings. It's more about having defaults that could be supposed by modules.
The only way *I* can think of that is, like Adam Johnson just
said: after INSTALLED_APPS = [...], add some kind of
from django.conf import load_app_settings
for key, value in load_app_settings(INSTALLED_APPS):
globals()[key] = value
(Sorry for this maybe shitty code hack)
Which then loads everything from installed apps - and later lines would override these "defaults"...?
I don't even know if this is possible.
On 7 May 2019, at 17:49, Christian González <christian...@nerdocs.at> wrote:Apps should have the possibility to add DEFAULT settings to the Django global settings. As already mentioned in my plugin system question, I don't see a problem with app/settings loading order. The loading order is done in INSTALLED_APPS, immutable, and good as it is.
App A could e.g. have a WEBPACK_LOADER variable that is imported into the global scope, and the settings.py then CAN override it.
It's that Django's settings.py SHOULD remain the master of settings. It's more about having defaults that could be supposed by modules.
On 7 May 2019, at 17:15, Christian González <christian...@nerdocs.at> wrote:I myself am using an implementation like DRF does it:
They create a class "APISettings", and mimic the Django behaviour.
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.
Ok, interesting approaches, but I think it's not exactly what I meant...
What you describe is, apps having its *own* settings, which are
possibly declared in <App>Config.ready(), by first importing
global settings, and having defaults if they are not present. But
this is only possible/usable for the app ITSELF.
I had tested various ways of this too, but came to another
problem: what if an app depends on another one, and wants to
provide sane default for that one?
What I meant is best explained with an example.
Like I mentioned earlier, I am currently trying to create a
"generic" plugin system for Django apps. I don't think my code is
good enough for getting this into core any time, but anyway.
My approach is adding one app "gdaps" to an Django application, and this app creates a few helper classes and methods which enable automatically finding of GDAPS plugins. You can enable any Django app with that feature "pluggability" then.
And here's the settings issue: As example, I have a submodule "gdaps.frontend" which provides frontend support (Vue, React, etc.) for the to-be-created Django application. gdaps.frontend depends on DRF and django-webpack-loader.
What I would like to do now, is that this gdaps.frontend app
provides *default settings* for another, namely
django-webpack-loader app, meaning adding a WEBPACK_LOADER
attribute to global settings.py - which is not possible by design
now. At the first glance this would break encapsulation dogma,
but: It's nothing more that one app depends on another app, and
uses it's features. This is perfectly valid IMHO.
Concise: It's necessary because I'd like to have as much automatisms as possible with sane defaults for the user that adds GDAPS to his Django application. Just adding "gdaps.frontend" to the INSTALLED_APPS (and one management command) would then, in my imagination, provide a fully configured webpack/frontend stack, ready to go.
Which needs a configured WEBPACK_LOADER attribute in settings.py, or elsewhere, but where django-webpack-loader can receive/load it, by normal Django app loading mechanism.
The only way I could think of is iterating over all apps, and merging all their settings files into the global one. This has to be done WITHIN the settings.py.
There are some problems I can think of:
1) You have to add code to settings.py which "finds" the other
plugins. Not a problem, I already do this in GDAPS.
2) if you define FOO = {"BAR": 5} as default in a sub app, you can't easily add a FOO setting in the global settings.py by FOO = {"BAZ" = 4 } - the two wouldn't be merged, but overwritten. The user writing the global settings can't know if there IS a default already.
As long as settings.py is a code file, this can't be solved
easily:
-> first "importing" all apps' settings, then the global one can't be done, as you need global settings to even KNOW which apps are installed... chicken-egg-problem.
-> first importing settings.py, and then all apps would be ok, but the mechanism must be VERY sensitive to not override settings already defined in the global settings.py by settings imported afterwords from apps.
Only thing I can think of would be settings that are declared,
e.g. an ini file. There are approaches - but I don't think this is
the way to go neither. So I'm clueless here.
3) security: settings.py should be only readable by the webserver, other packages (and their settings files) could be readably by others, and could contain sensitive information. This is not very likely, and could be "workarounded" by "Just don't do it."
2. Set a default value at import time:
# apps.py
[...snip...]
def ready(self):if not hasattr(settings, 'MY_SETTING'):settings.MY_SETTING = 'my_default'
This would be more like I meant it - but AFAIK, this MY_SETTING is not available globally then? E.g. by apps that are ordered below the app in INSTALLED APPS that declared MY_SETTING?
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.
Best regards,
Sorry about writing, and not testing myself before:
2. Set a default value at import time:
# apps.py
from django.apps import AppConfigfrom django.conf import settings
class MyAppConfig(AppConfig):name = 'my_app'verbose_name = "..."
def ready(self):if not hasattr(settings, 'MY_SETTING'):settings.MY_SETTING = 'my_default'
This works.
I have an app that has the following code in <app>Config.ready():
settings.WEBPACK_LOADER.update( { "foobar": { "STATS_FILE": os.path.join( settings.BASE_DIR, "{}/frontend/webpack-stats.json".format( os.path.abspath(os.path.dirname(__file__)) ), ) } } )
And the app webpack_loader is located *after* this app in INSTALLED apps. Within webpack-loader, the settings dict WEBPACK_LOADER inclusive "foobar" is available. So this is kind of "solved" for me - but - it's a bit of a hack.
I'd really appreciate a "standard" approach from Dajngo...
Thanks for your patience, ;-)
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/3727cd68-3ed6-1366-2277-0815ae90da5c%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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/3727cd68-3ed6-1366-2277-0815ae90da5c%40nerdocs.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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
It looks like app maintainers really ought to give django-gdaps a shot. Perhaps Christian, another way would be to contribute gdap support to the apps you like to use in the ecosystem. Then their maintainers could benefit from it if they install gdaps and so it can propagate in the ecosystem, and you can consolidate your patterns.
That's what I wanted when I created GDAPS. It should be an extension, and not replace Djangos app loading mechanism. Not all applications are designed to be pluggable, so a deterministic order in INSTALLED_APPS is fine. How I designed it, was meant to *enable* Django apps to be pluggable just by adding gdaps to INSTALLED_APPS.
But yes, this "sane defaults" what I need there would be handy in lots of other Django apps, like you mentioned django-debug-toolbar.
And it's not about settings, but also e.g. urlpatterns - apps should be able to inject them too. I found a way that works in GDAPS, using my (adapted from pyutilib) plugin system.
The main settings/urls.py file could/should always be the master - this is different in every application. Think of ordering urls.