I’m happy with this approach, it’s a little step forwards towards maintainable settings files.
On Sun, 27 Nov 2022 at 20:37, 'Tobias McNulty' via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > Hi Raphael, > > Thanks for taking this on. > > Starting with a limited scope seems like a good idea to me. > > A couple other things I like about this approach: > > - It tackles cache URLs at the same time (it makes sense for them to > mirror one another, IMO). > - No implicit usage of DATABASE_URL, but as you said it still supplies an > easily searchable answer for "Django DATABASE_URL." > > Cheers, > Tobias > > > On Sun, Nov 27, 2022, 2:40 PM Raphael G <r.gaschign...@gmail.com> wrote: > >> Some base industry background. It's a pretty common convention to share >> credentials in environment variables. For many PaaS, it's common to use >> connection URLs to do so. So DATABASE_URL will have a URL like >> postgres://my_user:mypassword@somedomain/database stuffed into a single >> environment variable. >> >> Django expects a configuration dictionary for its drivers. So what do >> people do? People install django-database-url, and pass in the string >> into that library (or rather, the library will read a blessed environment >> variable). Absent that they'll need to manually parse out the information >> and build the configuration dictionary. So if you just have Django time >> to futz around with urlparse >> >> There have been some discussions about how to make this better, including: >> >> - adopting dj-database-url as an "official django project" via DEP 7 >> >> <https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ> >> - instead adopt a behavior where Django will automatically handle a >> string as an alternative to a configuration dictionary >> <https://pypi.org/project/django-service-urls/> (this is discussed in >> the first link as PR 10786) >> - Integrate dj-database-url but expand on it a bit to also help with >> cache configuration, and have backends handle URL parsing >> >> <https://groups.google.com/g/django-developers/c/G0TtlhH2RUE/m/ShwTToPDAgAJ> >> >> These haven't seen much movement in the past couple of years. A comment >> in one of these e-mail threads: >> >> > I suspect this is a "good enough is good enough" situation. Something >> like what Raffaele is talking about, or dsnparse, or whatever would >> probably be ideal. And for something to be merged into core, I think it'd >> need to be a more full solution than just dj-database-url. >> >> dj-database-url takes something from an environment variable and >> provides a configuration dictionary. There's this feeling that having >> Django directly accept a string would feel more natural and correct. There >> are also other libraries like dsnparse, and people proposing things like >> adding a DSN name into settings. >> >> I think of all the options, the third option (the proposal by Tom Forbes) >> is a very good option. What it looks like in practice is the addition of >> the following: >> >> - the ability for database backends to register protocol names for >> URLs, so that postgres://localhost:5432 will properly map to the >> django.db.backends.postgresql backend, but people can show up with >> their own mappings. >> - A configure_db(url) function, that will return a configuration >> dictionary meant for DATABASES >> - A similar configure_cache(url) function that will give cache >> configuration dictionaries meant for CACHES >> >> A thing that is notably absent here is any blessing of DATABASE_URL. You >> have to do >> >> DATABASES = { >> 'default': configure_db(os.environ['DATABASE_URL']) >> } >> >> yourself. It's not "ideal" in that you don't magically get behavior from >> your URLs, but that also means you're just doing something in a >> straightforward way that should be easy to debug with some print statements >> when needed. It feels way less likely for this to be a major design miss. >> >> The motivating examples for the two above being supported is that Heroku >> will provide DATABASE_URL and REDIS_URL. >> >> The nice thing about this solution is that it doesn't block future design >> space. We get a configuration dictionary that matches the existing >> functionality, because the added API is simple it's easy for people to >> inspect the results, and of course it doesn't preclude people from keeping >> on with their existing solutions. There isn't even an assumed usage of >> DATABASE_URL like with dj-database-url! Mostly magic free. >> > I tried to rebase the PR >> <https://github.com/django/django/pull/16331#issuecomment-1328232653> >> including >> the above functionality from a couple years ago, and added some basic >> documentation. This doesn't try and convince users to use this, but I >> believe the usage would be sufficient for simple cases. >> >> So my ask here: how do people feel about moving forward with this limited >> scope? Previous discussions talked about wanting a larger scope for it to >> get merged into core. I believe that instead targetting a smaller scope >> means we can at least provide a workable answer to the DATABASE_URL question >> in the near term. And when consensus coalesces around a good overall answer >> to settings, the actual URL parsing logic will already be present and even >> more battle tested. >> >> -- >> 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/d990fef4-586b-447f-afd1-b53f23237a3an%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/d990fef4-586b-447f-afd1-b53f23237a3an%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/CAMGFDKQeN-Y-q8RsTOfpF%2BD%3Dk6%2B7pDt3zUv3AETavJStxRFFfA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMGFDKQeN-Y-q8RsTOfpF%2BD%3Dk6%2B7pDt3zUv3AETavJStxRFFfA%40mail.gmail.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/CAMyDDM0Nv6-8tJLYwWB1BSgDhVx%2BX_PHx6k8SHMigOVKg_106A%40mail.gmail.com.
