> 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.
Yes and I think
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
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
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
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
(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
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) wrote:
> Hi Raphael,
>
> Thanks for taking this on.
>
> Starting with a limited scope seems like a
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
Am 27.11.22 um 13:51 schrieb Raphael G:
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
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
10 matches
Mail list logo
