Hey Tobias.

> Could you (or others) provide some examples of the needs this solution
doesn't address (not necessarily complete, just to give an idea)?

I hadn't seen the other thread this morning when replying to this one. It
looks like some of the issues are indeed addressed *but *I was only able to
give the historical discussion a quick read — I can't if it's Job Done™ — I
kind of feel that review falls to the proposal.

>From my glance, all positive points:

* The register functions for a backend look quite flexible.
* The cache case was covered.
* The need to wire-up the configure functions looked to resolve somes
concerns too.

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.)

Kind Regards,

Carlton

On Mon, 28 Nov 2022 at 14:03, 'Tobias McNulty' via Django developers
(Contributions to Django itself) <django-developers@googlegroups.com> wrote:

> Hi Carlton,
>
> Responses inline below:
>
> On Mon, Nov 28, 2022, 2:40 AM 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.
>>
>
> Isn't this already a more full solution insofar as it supports setting
> CACHES as well? This may or may not be correct, but I read the history a
> little differently, more that "life happens" and no one quite found the
> energy to push the current solution over the finish line (I empathize
> completely!).
>
> 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.
>>
>
> I agree 100%, and I feel like we can and will take this into consideration
> sufficiently as we refine the current solution, if we continue down this
> path.
>
>  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.
>>
>
> Could you (or others) provide some examples of the needs this solution
> doesn't address (not necessarily complete, just to give an idea)?
>
> Many thanks,
> Tobias
>
> --
> 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/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%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/CAJwKpyQE%2BCGB0YtFF_%3DKbSwDt-AbvNQO4CHTdBBA5XUaHECTOA%40mail.gmail.com.
  • R... Raphael G
    • ... Carlton Gibson
      • ... Carlton Gibson
      • ... 'Tobias McNulty' via Django developers (Contributions to Django itself)
        • ... Carlton Gibson
          • ... James Bennett
            • ... Curtis Maloney
            • ... Carlton Gibson
              • ... Florian Apolloner
                • ... 'Tobias McNulty' via Django developers (Contributions to Django itself)

Reply via email to