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.
