I see you posted afresh in the other thread, addressing some of the points here. C.
On Mon, 28 Nov 2022 at 08:39, Carlton Gibson <carlton.gib...@gmail.com> wrote: > Hi Raphael, thanks for picking this up. > > Looking at the history here, particularly the discussion here > https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ > but there are others, the reason this hasn't already happened is that if > we're going to merge this into core it would be nice (required?) to handle > extra cases than (to paraphrase) "just what Heroku expects". > > It doesn't look like anyone has sat down to spec out exactly what that > means, but there seem to be plenty of thoughts in the discussion. ... 🤔 > > JKM's comment on the thread there is representative of the general > thought: > > > 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. > > The trouble with merging a suboptimal solution is that once it's in, it's > *very > hard* to change. We have the whole API stability policy to contend with > (and rightly so). > We bring in a half-baked solution; likely "recommend" it (for some value > of that) and then face a long stream of difficult adjustments whilst we try > and accommodate the necessary adjustments. > > Given that dj-database-url is stable, a single line install, and (most > importantly) not being developed to try and accommodate the issues that > stopped it just being merged into core already, I think it should continue > to live as a third-party package. > > The place for the development to happen is in dj-database-url or a > successor package. (The first step would be a Roadmap drawn from the > historical discussion.) > Once (if) that gets to the point where it clearly addresses the 90% of > needs, then there's a case for adding it to core. I don't think we can just > push forward given that nothing changed in the last few years. > > Kind Regards, > > Carlton > > > > On Sun, 27 Nov 2022 at 20:40, Raphael G <r.gaschign...@gmail.com> wrote: > >> Alright, I tried to revive Tom Forbe's work on this in >> https://github.com/django/django/pull/16331 >> >> My honest feeling here is that if Django existed just for me, I would >> really just want to get this pulled in as an option, and trying to increase >> the scope beyond "given a URL, get a dictionary of settings" is a tarpit >> that is not worth venturing into in a first merge. Though it's definitely a >> tarpit worth venturing into as a future step! >> >> So my strategy here was to try and get this as close to mergeable as >> possible, with as few points of discussion needed as possible. I tried to >> document what Tom did, more or less disregarded the idea of providing DSN >> support in settings, and for memcache avoided blessing an "official" >> backend. The main thing should be that if people google Django DATABASE_URL >> there should be a good answer in the docs, IMO. >> >> As someone who's dealt with custom backends in various parts of Django, >> and with libs, I think Tom's simple registry pattern for custom protocols >> is more than sufficient for library writers. >> >> Documentation is minimal, but exists. While I basically expect people >> writing custom DB backends or cache backends to directly look at the >> source, at the very least we are pointing to the existence of functions for >> registration in the docs in this PR. >> >> I'm sure we all have these simple projects that really don't need to do >> much, we all have been pulling in dj_database_url on the side to get this >> and feeling a bit off about it, so let's try and get that use case handled >> in a way that doesn't prevent further niceness in the future! >> >> Raphael >> On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote: >> >>> Hi all, >>> I'm working on https://github.com/django/django/pull/10786 (which is a >>> port of https://pypi.org/project/django-service-urls/ , which is a >>> 'fork/rewrite' of Tom PR). >>> I need to (re)read all these emails to find ideas to improve the >>> PR/package. >>> >>> On Sat, Jul 28, 2018 at 9:44 PM Tom Forbes <t...@tomforb.es> wrote: >>> >>>> So in the PR I proposed I only bits I took verbatim from >>>> dj-database-url are the tests. The rest is re-implemented. I think it's a >>>> pretty good POC but I haven't touched it in a while. >>>> >>>> In any case we have to implement our own parsing for backends that do >>>> not support passing in a URL to the connection library. >>>> >>>> Making postgres skip our parsing step and passing it in directly is an >>>> implementation detail and there are much more important questions around >>>> the API design to answer before this has any chance of being included. >>>> >>>> On Sat, 28 Jul 2018, 12:57 Maciej Urbański, <roote...@gmail.com> wrote: >>>> >>>>> I would agree that DSN support seems like a nicer alternative to just >>>>> copying dj-database-url, because it not only focuses on 12factor >>>>> configuration in enviroment variables, but also enables some additional >>>>> flexibility for the database connection option passing. >>>>> >>>>> As for 12factor, I think https://gist.github.com/telent/9742059 is a >>>>> good read as to why exposing as enviroment variables maybe not the best >>>>> motivation. Having to accommodate settings, like database connection >>>>> information, just so they can be fitted into single string put conveyable >>>>> by enviroment variable is a case in point. We likely can do the same for >>>>> Cache addresses as mentioned previously, although we may end up inventing >>>>> new URI schemes do to that.., but django overall has multitude of other >>>>> options that are not as easy to stringify. >>>>> >>>>> On Friday, 27 July 2018 19:14:12 UTC+2, gw...@fusionbox.com wrote: >>>>>> >>>>>> I'd like to approach this as 'support database urls in django', >>>>>> rather than 'copy/paste dj-database-url into django'. For postgres (I'm >>>>>> not >>>>>> sure about other backends), a database url can be passed directly to >>>>>> psycopg2. The postgres connection string format actually supports more >>>>>> features than is possible with django's HOST/USER/PORT... style settings. >>>>>> For example, you can pass multiple hosts and psycopg2 will attempt to >>>>>> connect to one of them: >>>>>> https://paquier.xyz/postgresql-2/postgres-10-multi-host-connstr/. >>>>>> Any attempt to parse the url in django will result in a loss of those >>>>>> features. >>>>>> >>>>>> The only problem I see is that we have to parse the database backend >>>>>> out of the url, and you can't pass a url like 'postgis://....' to >>>>>> psyscopg2. I'd like to be able to do something like: >>>>>> >>>>>> DATABASES = { >>>>>> 'default': { >>>>>> 'DSN': 'postgres://....', >>>>>> 'ENGINE': 'django.contrib.gis.db.backends.postgis', >>>>>> }, >>>>>> } >>>>>> >>>>>> And let psycopg2 handle the DSN. >>>>>> >>>>> -- >>>>> 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 post to this group, send email to django-d...@googlegroups.com. >>>>> Visit this group at https://groups.google.com/group/django-developers. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/1a55cc1c-ba9c-4950-ab94-50da8eec7d06%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/django-developers/1a55cc1c-ba9c-4950-ab94-50da8eec7d06%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> 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 post to this group, send email to django-d...@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/django-developers. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CAFNZOJMa1xSzBeGUYygG7nxfCVz8jUPNEiSEJhbAqLDTwga9BQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-developers/CAFNZOJMa1xSzBeGUYygG7nxfCVz8jUPNEiSEJhbAqLDTwga9BQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> | Raffaele Salmaso >>> | https://salmaso.org >>> | https://bitbucket.org/rsalmaso >>> | https://github.com/rsalmaso >>> >> -- >> 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/20a991ee-1601-4969-b12d-272cd9a1556an%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/20a991ee-1601-4969-b12d-272cd9a1556an%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/CAJwKpyTswkFugYOYX4XH0MZDWp%3DkGu2O7RcGEUUGP539WXfqqw%40mail.gmail.com.
