Hi Peter,
On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
wrote:
> 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.
>
Agreed, I should have written this better. I expect there to be plenty of
different opinions on this topic and it might be hard to figure out the
one-size-fits-most without being to limiting.
> * 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
>>
>
> Yep, 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.
>
Sure and with limiting access I was more thinking about source IPs than
actual logins (ie open health endpoint to the internal network from which
the loadbalancer connects)
> * 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'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.
>
Jupp, that is also the reason why I am in a love/hate relationship with it
:)
> * 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.
>
Yes, being able to override stuff via env variables should probably be
always allowed. And as long as we do have a "schema" of some kind (be that
via config.get_bool or typing annotation on a configuration object) it is
also relatively easy to convert env variables to their correct form (ie
boolean).
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.
>
Yes and no. A 3rd party dependency will make it certainly harder to get
this merged upstream. On the other hand I wouldn't want to support env
variables only in the first iteration if that makes adding support for
"properly" typed schemes (yaml/toml) harder in the future. From a viability
point I'd like to see that we have an API that can handle hierarchical
typed config and env variables. If we get that right the reasons to use
something else will be rather small I guess.
> Had another thought here... what about providing a pluggable
configuration backend? Django could ship with some native backends like
environment variables and toml (when it's available). Third party packages
could provide Vault, secret files, etc. Same as how storages currently
works and how you can easily drop in something like django-storages.
Yes, the main question though is how the api contract would look like and
how we are going to "solve" the chicken egg problem of how those backends
are activated? We cannot really put `SETTING_LOADERS =
["django.settings.loaders.env", "django.settings.loader.toml"]` into a
`settings.py` file and then use `config.get("DATABASE_URL")` just below to
use the DATABASE_URL. So like `DJANGO_SETTINGS_MODULE` this would be
something that has to be in an env var before Django starts. But I guess
that would mostly be okay and projects might be able to pass their own
loaders to `django.setup()` or configure their `.wsgi` files accordingly.
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-developers+unsubscr...@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.
