The thread that Carlton refers to is
https://groups.google.com/g/django-developers/c/q20_Cxske88 -- don't be
deterred by the title of it, it really talks about handling settings as
well :)
I kinda agree with James. I'd like to have a proper answer for handling
settings rather then go setting by setting. The main difficulty I see is to
decide whether we really go low-level in the sense of providing a simple
API that can get settings from a variety of sources (the `get("key",
default)`) or if we go further and provide a newer opinionated high level
API like pydantic etc… Both approaches have their ups and downs. But before
repeating everything from the other thread here, I'd like to ask that we
decide on one spot to continue this discussion and then stick to that one
(the settings one, as noted by James I am also rather -0 on adding
DATABASE_URL support now). Titlewise neither of the two threads seem to fit
very well so we can just as well open a topic on the forum ;)
Cheers,
Florian
On Tuesday, November 29, 2022 at 8:09:17 AM UTC+1 carlton...@gmail.com
wrote:
> This must be do-able now.
>
> There was some discussion of something along these lines a couple of years
> ago, with the idea of doing it for GSoC.
> There was much back-and-forth but no consensus.
>
> It has then come up again with Peter's suggestions about making it easier
> to get to a deployment ready state.
> The discussion with Florian there touches on this exact point.
>
> It looks like there's two sides to it:
> * A user-facing API, perhaps like ...get("key" default) 🤔
> * A pluggable backend API for that, so folks can use things like Vault and
> temporary secrets files as well as the environment.
>
> If I followed correctly, it would be OK to ship an environment backend
> with Django (perhaps with some simpler ones for development/testing)
> leaving more advanced options open.
> I think Florian has ideas here.
>
>
> On Mon, 28 Nov 2022 at 23:20, James Bennett <ubern...@gmail.com> wrote:
>
>> It feels like this needs to be a broader conversation about not just
>> changing DATABASES to accept a URL, or integrating a particular
>> database-settings project, but to re-think how Django does
>> settings-from-environment as a whole.
>>
>> When I'm setting up new Django-based projects, django-environ
>> (https://pypi.org/project/django-environ/) is now one of the first
>> packages I reach for, and it has a much more comprehensive set of
>> helpers for configuring Django from environment variables and doing
>> appropriate parsing and type casts.
>>
>> There also is Pydantic's settings model
>> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
>> annotations to drive parsing/validation/type-casting and defaults to
>> reading from environment variables.
>>
>> I'd rather see some sort of comprehensive "make settings-from-env
>> easier" in Django than one-off pieces like a database URL.
>>
>> --
>> 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/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com
>> .
>>
>
--
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/dd5a98e9-a7f7-4db8-a61d-697210bd6970n%40googlegroups.com.
