config.get is how python-decouple works which is what I use for config and
deployment settings.
On Tuesday, 1 November 2022 at 09:34:15 UTC f.apo...@gmail.com wrote:
> 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)`.
>
> On Tuesday, November 1, 2022 at 3:35:46 AM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner <f.apo...@gmail.com>
>> wrote:
>>
>>> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
>>> wrote:
>>>
>>>> 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?
>>>>
>>>
>>> I doubt that will ever fly. There is no project so to say in Django.
>>> Currently literally everything depends on knowing a
>>> `DJANGO_SETTINGS_MODULE` from which everything else can follow (even the
>>> wsgi app…). So without a settings file how would you know that hard-coded
>>> path for it? Django has no concept of a project that you could import. You
>>> also cannot easily put `CONFIG_LOADERS` in a settings file like we
>>> currently have because then how are you going to evaluate that while also
>>> executing all the other module level stuff. And django-admin command all
>>> already support a `--settings` flag (as alternative to
>>> DJANGO_SETTINGS_MODULE ;))
>>>
>>> Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time
>>> soon. And I don't see it such of a problem with being there. Projects can
>>> set it (and startproject already does this) to a fixed value in manage.py &
>>> wsgi.py. For a project that installs a custom entrypoint script, you can
>>> also preset it to whatever you like.
>>>
>>> Please note that we are trying to load stuff from files & env vars in
>>> the first step, not throw out settings.py at the same time…
>>>
>>
>> I figured it wouldn't fly :)
>>
>> I misunderstood your chicken-egg question above. What I've been doing is
>> defining a "Config" class and instantiating it in the settings file.
>> Instantiation of the class (or calling an explicit method on it) would do
>> the env/file loading and the instance becomes your `env` object. Rather
>> than having a CONFIG_LOADERS setting, you could define them on the Config
>> class or when you instantiate it. This is pretty similar to how goodconf
>> works today. https://github.com/lincolnloop/goodconf#quick-start
>>
>>
>>>
>>> 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
>>>
>>> <https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%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/5ebb70e7-9118-4989-9a32-7b1faa9f032dn%40googlegroups.com.
