Re: Potential way forward for DATABASE_URL
OK after looking at this some more and trying to write up a review aid, I'm giving up on this branch and trying to integrate DATABASE_URL support into Django proper. A couple reasons: - I misread the original mailing list thread which made me think there was a consensus on this branch, and there wasn't. - There are a lot of tiny backend-specific things going on that are in because... well because django-database-url has that backend-specific behavior - Lots of people want the cache backend as a part of this. I'd be happy to have it. But basically every cache backend has weirdness (what's a service URL for the dummy backend? do we really need one for the file backend?), so ... I don't even know what makes sense there, honestly. So there's this dual thing of not wanting to "just" vendor django-database-url, but really the original branch that I tried to revive was either "just vendor that library" (battle tested) or "explore doing this for caches as well" (not battle tested). On top of all of this really apart from postgres I'm having a hard time finding docs for URLs that are "industry standard" for much of anything. So I'm trying to write up examples or justification for code I'm barely convinced of. This might be a thing where if there was a workshop day at a conference then a group of people with diverse experiences on various systems could land on a convincing thing and build consensus, along with a wonderful patch. But staring at this just feels like a tarpit for me. Especially given the sort of pressure to get the API right on the first shot. Anyways if I were the only person working on Django I would sidestep all of this by throwing dj_database_url into django.contrib and relying on the years of usage by everyone as "proof" that the thing works. And I think the branch I tried reviving is "correct", I just don't have the background in most of these backends to know if it's right. On Tuesday, November 29, 2022 at 5:41:41 PM UTC+9 Raphael G wrote: > Alright, I'm writing up a review aid that tries to re-explain the actual > changes in the PR I opened before. This document should go over all of the > actual API changes that are exposed to users as well. I believe the API > _is_ correct, and that future settings improvements could rely on these to > implement their features (so in the larger discussion, this is offering a > low-level API while an overarching high-level settings API is still being > worked on). At the end of the day there are only so many ways to structure > a dictionary containing a hostname, port, username, and password! > > But of course the specifics are important here, so I will finish up a > review aid and paste that in the PR (along with actually getting that > branch passing) discussion and crosslink it here. > On Tuesday, November 29, 2022 at 4:45:12 PM UTC+9 carlton...@gmail.com > wrote: > >> Hey Raphael. >> >> My only query is as we sure the API is correct going forward? >> The answer could be yes there, but I didn't (as yet get to) review the >> history in depth. >> >> We **can** deprecate things, but we get an awful lot of complaints and >> pushback, even changes that are clearly for the good. >> I'd rather measure twice and cut once is all. >> The whole point of the "Do it in a third-party app" approach is that we >> get to make sure the APIs are right, without adding churn to Django, >> and without being tied to the long-release cycle fixing the unforeseen >> issues that arise. >> >> Kind Regards, >> >> Carlton >> >> On Tue, 29 Nov 2022 at 06:45, Raphael G wrote: >> >>> (I'm very sorry about the threading going on here, I originally replied >>> to the very old mailing thread and then realized it had not generated >>> consensus, so am going to try and make this thread a more focused >>> discussion regarding concensus) >>> >>> In the other thread people are discussing more generalized setting >>> helpers. I am trying to avoid this, most because I think this work doesn't >>> exclude that work. But also I don't want to introduce more magic >>> personally, nor do the work involved in the settings magic personally. >>> os.environ is straightforward IMO. >>> >>> Carlton posted the following comment: >>> >>> > Given that it's a single import I might still lean towards seeing it >>> as an external package, at least for a cycle, so unknowns that come up can >>> be resolved, and folks on an older LTS can opt-in early, etc. >>> (But that's not a point of religion.) >>> >>> I am OK with putting in work to have it as a separate package for a >>> cycle. The glib comment would be that dj-database-url was that package for >>> many cycles, but this is not very true in practice. This is introducing >>> extra things not originally present for cache configuration, and has this >>> concept of the database backends holding the parsing logic. And of course >>> there's an extremely valid underlying point here: the API re
Re: Potential way forward for DATABASE_URL
To be clear, "pressure to get the API right on the first shot" is a statement of fact about adding APIs to a heavily used project in general, not a comment on anything said in this mailing thread. Just that in this case there's a lot of ways to get the ergonomics wrong. On Wednesday, December 21, 2022 at 12:06:44 AM UTC+9 Raphael G wrote: > OK after looking at this some more and trying to write up a review aid, > I'm giving up on this branch and trying to integrate DATABASE_URL support > into Django proper. > > A couple reasons: > > - I misread the original mailing list thread which made me think there was > a consensus on this branch, and there wasn't. > - There are a lot of tiny backend-specific things going on that are in > because... well because django-database-url has that backend-specific > behavior > - Lots of people want the cache backend as a part of this. I'd be happy to > have it. But basically every cache backend has weirdness (what's a service > URL for the dummy backend? do we really need one for the file backend?), so > ... I don't even know what makes sense there, honestly. > > So there's this dual thing of not wanting to "just" vendor > django-database-url, but really the original branch that I tried to revive > was either "just vendor that library" (battle tested) or "explore doing > this for caches as well" (not battle tested). On top of all of this really > apart from postgres I'm having a hard time finding docs for URLs that are > "industry standard" for much of anything. > > So I'm trying to write up examples or justification for code I'm barely > convinced of. > > This might be a thing where if there was a workshop day at a conference > then a group of people with diverse experiences on various systems could > land on a convincing thing and build consensus, along with a wonderful > patch. But staring at this just feels like a tarpit for me. Especially > given the sort of pressure to get the API right on the first shot. > > Anyways if I were the only person working on Django I would sidestep > all of this by throwing dj_database_url into django.contrib and relying on > the years of usage by everyone as "proof" that the thing works. And I think > the branch I tried reviving is "correct", I just don't have the background > in most of these backends to know if it's right. > > > > > > On Tuesday, November 29, 2022 at 5:41:41 PM UTC+9 Raphael G wrote: > >> Alright, I'm writing up a review aid that tries to re-explain the actual >> changes in the PR I opened before. This document should go over all of the >> actual API changes that are exposed to users as well. I believe the API >> _is_ correct, and that future settings improvements could rely on these to >> implement their features (so in the larger discussion, this is offering a >> low-level API while an overarching high-level settings API is still being >> worked on). At the end of the day there are only so many ways to structure >> a dictionary containing a hostname, port, username, and password! >> >> But of course the specifics are important here, so I will finish up a >> review aid and paste that in the PR (along with actually getting that >> branch passing) discussion and crosslink it here. >> On Tuesday, November 29, 2022 at 4:45:12 PM UTC+9 carlton...@gmail.com >> wrote: >> >>> Hey Raphael. >>> >>> My only query is as we sure the API is correct going forward? >>> The answer could be yes there, but I didn't (as yet get to) review the >>> history in depth. >>> >>> We **can** deprecate things, but we get an awful lot of complaints and >>> pushback, even changes that are clearly for the good. >>> I'd rather measure twice and cut once is all. >>> The whole point of the "Do it in a third-party app" approach is that we >>> get to make sure the APIs are right, without adding churn to Django, >>> and without being tied to the long-release cycle fixing the unforeseen >>> issues that arise. >>> >>> Kind Regards, >>> >>> Carlton >>> >>> On Tue, 29 Nov 2022 at 06:45, Raphael G wrote: >>> (I'm very sorry about the threading going on here, I originally replied to the very old mailing thread and then realized it had not generated consensus, so am going to try and make this thread a more focused discussion regarding concensus) In the other thread people are discussing more generalized setting helpers. I am trying to avoid this, most because I think this work doesn't exclude that work. But also I don't want to introduce more magic personally, nor do the work involved in the settings magic personally. os.environ is straightforward IMO. Carlton posted the following comment: > Given that it's a single import I might still lean towards seeing it as an external package, at least for a cycle, so unknowns that come up can be resolved, and folks on an older LTS can opt-in early, etc. (But that's not a po
