--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6K9zk5PmcxYWXRdvco1pWXnO%2BHoYoYHf0pg5Mw%3DgmdefZArg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6K9zmVDKcpM%3Dc9tyhrp2_K_dzLH5S9zMJcZSXduF9NkcoCKA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/493f7f12-541c-4e12-ac25-0fd341ce2dc2n%40googlegroups.com.
IMHO, adding YAML support would introduce a dependency that's not needed: why not just use Python, instead of ini/yaml/toml?
Projects could have a (.gitignore) env.py that settings.py
imports and then sets the appropriate variables from it. You can
use straight assignment, e.g.
LANGUAGE_CODE = env.LANGUAGE_CODE
LANGUAGE_CODE = getattr(env, 'LANGUAGE_CODE', 'en-gb')
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c79db112-a965-4700-90b2-2bcdcd9d65a8n%40googlegroups.com.
Hi Pete,this does look interesting. And I agree that this is something that would be nice to have in core in one form or another. That said I think we have to do it iteratively (ie in smaller parts) and evaluate along the way.
Since you asked for feedback, I'll tell you what I'd do differently (and this is also a sign that production environment vary widely).
* As soon as health checks check something aside from simply returning a 200 status code I'd want to be able to limit access to them
* I like my dev env to be as close as possible to production so I usually also use whitenoise in dev. I had to many times where dev worked and whitenoise in prod failed then :D
* I do hate `DJANGO_ENV` but I guess there is no way around it. Currently my projects often piggy-back on DEBUG but that can be rather hard from time to time
* I prefer settings in settings files (ini/yaml/toml) as opposed to env variables that leak down the whole process-tree. django-environ does support this; that said there are other options like dynaconf which also support hashicorp vault which is a massive plus imo. Just being able to utilize vault for free from every django application out there would be stellar.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c79db112-a965-4700-90b2-2bcdcd9d65a8n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/801f7f20-d431-fcb7-c427-1827724ada56%40gmail.com.
Thanks for the thorough review Florian! Some comments inline...On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner <f.apo...@gmail.com> wrote:Hi Pete,this does look interesting. And I agree that this is something that would be nice to have in core in one form or another. That said I think we have to do it iteratively (ie in smaller parts) and evaluate along the way.Agreed. I think adding the additional settings with some sort of production switch is the least obtrusive place to start.Since you asked for feedback, I'll tell you what I'd do differently (and this is also a sign that production environment vary widely).Production environments do vary widely, but I don't think that should stop us from providing defaults that are one-size-fits-most. startproject already does this and users are welcome to adjust it how they see fit.* As soon as health checks check something aside from simply returning a 200 status code I'd want to be able to limit access to themYep, that seems reasonable. Although depending on the level of failure, you may not be able to log in to see them. Starting with just a view that responds with a 200 is reasonable.* I like my dev env to be as close as possible to production so I usually also use whitenoise in dev. I had to many times where dev worked and whitenoise in prod failed then :DAlso a good point... I'll add that.* I do hate `DJANGO_ENV` but I guess there is no way around it. Currently my projects often piggy-back on DEBUG but that can be rather hard from time to timeI'm open to other suggestions here, but am kind of in the same boat. There may be times when you briefly want DEBUG=True in a non-public deployed environment or DEBUG=False in a development environment. Overloading that makes those scenarios a challenge.* I prefer settings in settings files (ini/yaml/toml) as opposed to env variables that leak down the whole process-tree. django-environ does support this; that said there are other options like dynaconf which also support hashicorp vault which is a massive plus imo. Just being able to utilize vault for free from every django application out there would be stellar.I'm 100% in agreement here. I wrote goodconf [1] for this before I knew about dynaconf which does a lot of the same things. I would love to see Django adopt a split between "settings" (which I see as things that don't change across environments) and "configuration" (things that you set per environment). I did switch to django-environ's FileAwareEnv [2] which allows loading from files, but not in the yaml./toml sense. I didn't go all in here because I felt like it was a more controversial stance and at the end of the day, you probably still need to support environment variables because many (most?) PaaS providers don't have support for files like that.With the goal of getting something merged into Django eventually, I felt like environment variables were the lowest bar. We have precedence for loading from environment variables with DJANGO_SETTINGS_MODULE. Do you think a more full-featured library like dynaconf would make it harder to push some of this upstream? Users that want to use dynaconf or goodconf or whatever can still edit their settings and use those like they do today.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6K9zkoksAxEs1NPAVOw-e8JOn3Xn0w-NLbMOmm2gZOEHV-Hg%40mail.gmail.com.
Since you asked for feedback, I'll tell you what I'd do differently (and this is also a sign that production environment vary widely).Production environments do vary widely, but I don't think that should stop us from providing defaults that are one-size-fits-most. startproject already does this and users are welcome to adjust it how they see fit.
* As soon as health checks check something aside from simply returning a 200 status code I'd want to be able to limit access to themYep, that seems reasonable. Although depending on the level of failure, you may not be able to log in to see them. Starting with just a view that responds with a 200 is reasonable.
* I do hate `DJANGO_ENV` but I guess there is no way around it. Currently my projects often piggy-back on DEBUG but that can be rather hard from time to timeI'm open to other suggestions here, but am kind of in the same boat. There may be times when you briefly want DEBUG=True in a non-public deployed environment or DEBUG=False in a development environment. Overloading that makes those scenarios a challenge.
* I prefer settings in settings files (ini/yaml/toml) as opposed to env variables that leak down the whole process-tree. django-environ does support this; that said there are other options like dynaconf which also support hashicorp vault which is a massive plus imo. Just being able to utilize vault for free from every django application out there would be stellar.I'm 100% in agreement here. I wrote goodconf [1] for this before I knew about dynaconf which does a lot of the same things. I would love to see Django adopt a split between "settings" (which I see as things that don't change across environments) and "configuration" (things that you set per environment). I did switch to django-environ's FileAwareEnv [2] which allows loading from files, but not in the yaml./toml sense. I didn't go all in here because I felt like it was a more controversial stance and at the end of the day, you probably still need to support environment variables because many (most?) PaaS providers don't have support for files like that.
With the goal of getting something merged into Django eventually, I felt like environment variables were the lowest bar. We have precedence for loading from environment variables with DJANGO_SETTINGS_MODULE. Do you think a more full-featured library like dynaconf would make it harder to push some of this upstream? Users that want to use dynaconf or goodconf or whatever can still edit their settings and use those like they do today.
Regarding DJANGO_ENV, why not ship the template with two settings files and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new environment variable?
Maybe that would be controversial too, I'm not sure, but perhaps less so than introducing a new paradigm? In any event, perhaps a pluggable backend would allow everyone to be happy, or very nearly so... 😅
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRGRtfqKASW3Re2snr_HNGtmwYjTEOGFqC_U3X%3DToCq3Q%40mail.gmail.com.
Cheers,Florian
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c5e8a581-e3fd-441c-8429-150cb67a3ce9n%40googlegroups.com.
In my ideal scenario, the default is a hard-coded settings file for the project (deprecating DJANGO_SETTINGS_MODULE env var) and we have CONFIG_LOADERS defined in the settings that could do env, toml, etc. Perhaps things like django.setup,
django.core.wsgi.get_wsgi_application, and django.core.management.execute_from_command_line could accept the settings module as an argument? django-admin could accept a --settings flag?
Cheers,Florian--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com.
Right, that would work. I am wondering though if we want to go all in on a typed config object like that or in a first step only have a simple API like `config.get('DEBUG', cast=bool)`.