On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner <f.apollo...@gmail.com>
wrote:
> 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.
>
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-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
> <https://groups.google.com/d/msgid/django-developers/c5e8a581-e3fd-441c-8429-150cb67a3ce9n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAC6K9zmdRLpsxCKNowT15dbj5kgH7ZxAoEY5szk74S6UqEn4iA%40mail.gmail.com.
