subject:""

Just to clarify this point, which I think has been glossed over:

> But unless I'm misunderstanding the nature of the bug, this seems like it
basically makes async views un-testable ...

This isn't correct.

Under normal circumstances you just use the sync Client, as you've always
done. `response = client.get(`/my-async-view/`)`.
Django handles that the **view** is async for you.

It's only if you need to write an actual **async test**, i.e. an `async
def` test case that you need the async client and factory.

The factory can use the suggested `request.body` workaround if needed.
Where you need async def tests, dropping down to the request factory is
available. An example might be testing a middleware for async
support in isolation, which fits the request factory model directly.

The `AsyncClient` is affected, yes. The question is whether that justifies
a backport at this very late hour.





On Fri, 30 Dec 2022 at 23:59, Kevin Grinberg 
wrote:

> I'll say upfront that I haven't hit this particular issue, but it's mostly
> because I've avoided the Django async stack after some challenging
> experiences on the old(er) channels/daphne/etc. stack and its evolution.
> I've personally been in the "let's see how this develops" camp, which
> admittedly isn't the most community-focused. I'll resolve to do better in
> the new year.
>
> This does sort of get at one aspect of this issue though - there's less
> usage of the async stuff as it's being rolled out slowly across multiple
> releases (which it itself an experiment of sorts), in part because [at
> least] some people don't trust it to actually be stable and are waiting to
> see the whole story before committing projects more fully.
>
> So from the perspective of "how many users are impacted", I agree the
> impact is probably low. But unless I'm misunderstanding the nature of the
> bug, this seems like it basically makes async views un-testable without a
> pretty annoying workaround (assuming it's more than a handful of views)?
> Plus the fact that it's not easily discoverable.
>
> FWIW (I'm an n of 1 obviously), but I go LTS-to-LTS for most projects,
> just given uncertainty in when I'll be upgrading any particular project,
> and wanting to be certain I never fall out of support for at least security
> releases. So for my own personal needs, fair enough - by the time I migrate
> my 3.2 projects to 4.2, this will be fixed, and it's unlikely that I'll
> personally be experimenting with async views in the next 3 months or so.
> But that doesn't really seem like the sort of behavior we want to
> encourage, if we're trying to actually get people to use async, get some
> real-world usage, and signal that Django has a good async story.
>
> I'm very cognizant of maintenance burden and feel sheepish advocating for
> someone else to do work, but if this thread is asking for opinions, I do
> think it's important to backport this issue. I can't literally equate it to
> a data loss bug (the specific example in the policy), but I'd argue that
> the gradual nature of the async rollout and its importance in moving Django
> forward mitigates for an exception to the backport policy.
>
> Cheers,
> Kevin
>
>
> On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrote:
>
>> As perfectionists, it's always hard to say (and hear) "no" when this sort
>> of request comes up. I'm unconvinced it's a serious issue that requires a
>> break from normal policy. (Unreported for 2 years in 4 major releases;
>> simple workaround present.)
>>
>> Incidentally, escalating an issue to the steering council after less than
>> 24 hours (during a holiday week, no less) probably isn't something we want
>> to model as a best practice in forming consensus.
>> On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:
>>
>>> I have put it to the Steering Council:
>>>
>>>
>>> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>>>
>> --
> 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/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%40googlegroups.com
> 
> .
>

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

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 2:24 PM Tim Graham  wrote:
> As perfectionists, it's always hard to say (and hear) "no" when this sort of 
> request comes up.

I wrote a 2,000-word argument explaining why I believe this warrants
backporting. I think that deserves more engagement than just a "no".

> I'm unconvinced it's a serious issue that requires a break from normal 
> policy. (Unreported for 2 years in 4 major releases; simple workaround 
> present.)

I strongly encourage you to read the linked forum post, where I have
explained at length why I think it is serious enough to warrant an
exception (and why I believe the policy should also be
revisited/revised to accommodate cases like this explicitly).

> Incidentally, escalating an issue to the steering council after less than 24 
> hours (during a holiday week, no less) probably isn't something we want to 
> model as a best practice in forming consensus.

Reducing an opposing viewpoint to "it's hard to hear 'no'" probably
falls into that category, too. And I will point out here, as I did in
the forum thread, that the discussion here seemed to be blocked on a
Merger who was not convinced and *who suggested the Steering Council
as an option*. And procedurally, one point of the SC is to serve as a
"court of appeal" if someone cannot convince the Mergers of the merits
of a minor change.

Meanwhile, I think Kevin is pointing in the direction of something
important, which is that it is very easy to wind up in a vicious cycle
where people get the impression that Django does not take its async
story seriously and so they stay away from async Django, which then is
used as an argument for not taking the async story as seriously
(because obviously async Django is not that widely used), which then
gives people the impression...

Async is hard enough without Django making it harder still. So I think
it is important for Django to make clear that the async story is
supposed to be good and that the Django project is committed to
supporting async. Right now, a developer who decides to try out async
Django, with any currently-supported release, and follows the obvious
"how to test my async code" clues in the documentation, will very
likely end up with something broken. Worse: the breakage will be hard
to diagnose, harder to find out the workaround for, and if they do
manage to find it they'll likely also be treated to one or more
threads of the Django project saying that due to the technicalities of
when the breakage was first formally reported, none of the currently
released and allegedly bugfix-supported versions of Django are
actually eligible to receive a fix.

I put it to you that this is not a good experience for the developer,
that it is not the experience the Django project should be inflicting
on the developer, that it will tend to erode the developer's trust and
confidence in Django if this is the path Django decides to take, and
that the solution to all this is comparatively easy: backport the
frankly pretty minimal fix for the async test client into the full set
of currently-supported feature releases of Django as a show of good
faith and support, and to make async support easier for the community
and the overall ecosystem.

-- 
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/CAL13Cg8NAXWw3nLm0TbJH68i8zzgsHGBySJW459KEW81tbY85g%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread Kevin Grinberg

I'll say upfront that I haven't hit this particular issue, but it's mostly 
because I've avoided the Django async stack after some challenging 
experiences on the old(er) channels/daphne/etc. stack and its evolution. 
I've personally been in the "let's see how this develops" camp, which 
admittedly isn't the most community-focused. I'll resolve to do better in 
the new year.

This does sort of get at one aspect of this issue though - there's less 
usage of the async stuff as it's being rolled out slowly across multiple 
releases (which it itself an experiment of sorts), in part because [at 
least] some people don't trust it to actually be stable and are waiting to 
see the whole story before committing projects more fully.

So from the perspective of "how many users are impacted", I agree the 
impact is probably low. But unless I'm misunderstanding the nature of the 
bug, this seems like it basically makes async views un-testable without a 
pretty annoying workaround (assuming it's more than a handful of views)? 
Plus the fact that it's not easily discoverable.

FWIW (I'm an n of 1 obviously), but I go LTS-to-LTS for most projects, just 
given uncertainty in when I'll be upgrading any particular project, and 
wanting to be certain I never fall out of support for at least security 
releases. So for my own personal needs, fair enough - by the time I migrate 
my 3.2 projects to 4.2, this will be fixed, and it's unlikely that I'll 
personally be experimenting with async views in the next 3 months or so. 
But that doesn't really seem like the sort of behavior we want to 
encourage, if we're trying to actually get people to use async, get some 
real-world usage, and signal that Django has a good async story.

I'm very cognizant of maintenance burden and feel sheepish advocating for 
someone else to do work, but if this thread is asking for opinions, I do 
think it's important to backport this issue. I can't literally equate it to 
a data loss bug (the specific example in the policy), but I'd argue that 
the gradual nature of the async rollout and its importance in moving Django 
forward mitigates for an exception to the backport policy.

Cheers,
Kevin

On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrote:

> As perfectionists, it's always hard to say (and hear) "no" when this sort 
> of request comes up. I'm unconvinced it's a serious issue that requires a 
> break from normal policy. (Unreported for 2 years in 4 major releases; 
> simple workaround present.)
>
> Incidentally, escalating an issue to the steering council after less than 
> 24 hours (during a holiday week, no less) probably isn't something we want 
> to model as a best practice in forming consensus.
> On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:
>
>> I have put it to the Steering Council:
>>
>>
>> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>>
>

-- 
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/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%40googlegroups.com.

Re: Backport for ticket 34063?

2022-12-30 Thread Tim Graham

As perfectionists, it's always hard to say (and hear) "no" when this sort 
of request comes up. I'm unconvinced it's a serious issue that requires a 
break from normal policy. (Unreported for 2 years in 4 major releases; 
simple workaround present.)

Incidentally, escalating an issue to the steering council after less than 
24 hours (during a holiday week, no less) probably isn't something we want 
to model as a best practice in forming consensus.
On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:

> I have put it to the Steering Council:
>
>
> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>

-- 
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/7ef540fb-939f-4afa-9e05-33f988f6b0b0n%40googlegroups.com.

Re: Backport for ticket 34063?

I have put it to the Steering Council:

https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1

-- 
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/CAL13Cg9QdLJBK1K%3D-CO1%2BxvnCbw_X7sCG%2B%2BUSzFv84Jnb8khAA%40mail.gmail.com.

Re: Backport for ticket 34063?

> Even if it will not be fixed for older versions, Django 4.1 ought to be
eligible for a backport.

What you're suggesting is a change to the backport policy. That may be the
right thing to do, but it would be quite a significant change.
These issues — where a bug report/fix comes outside the backport period —
are quite common. It's always a bit frustrating that we can't backport, but
the stability of released versions has been taken (for years, by the whole
community — by the folks hitting the particular non-backported issue this
time :) as correct on balance.

> But this response to it is eroding my trust in Django, and I hope you
know that is not something I say lightly.

Since I'm the only person who's responded thus far, I can't help but read
that as saying it erodes your trust in me. That's sad. Especially since all
I've done is not agree with you. :)
Nonetheless you can invoke the Steering Council if no-one else responds,
and you feel it's as bad as all that.

> ...a critical time when Django is facing stiff competition...

Django's USP is stability and ease of update, not async. The backport,
stability, and supported versions policies are the cornerstone of that, I
believe. It's not something we should endanger.
Other frameworks move faster, but they don't have extended LTS lifetimes to
consider.

I see the success of FastAPI in particular. Super.
But I don't see it as any different to Flask, say, in the previous period.
May a thousand flowers bloom.
I don't see it as an existential threat to Django. Quite the contrary: What
a rich and wonderful time it is for the Python web framework ecosystem as
whole.
(This ecosystem is itself under threat from JavaScript, I'm constantly
told, which will not survive Rust, I hear, ... and so on.)

My view is that Django's async support is maturing nicely, slowly, but
nicely and it's grows every release. That will continue for a few more
cycles yet. Bug fixes in new features should be backported within the
policy yes, but not beyond that. Better guidance in the asynchronous
support docs saying, "hey, do update, this stuff is still growing" may well
be in order. I have this in the Channels 4.0 release notes
:
"The async support in both Python and Django continues to evolve rapidly.
We advise you to always upgrade to the latest versions in order to avoid
issues in older versions if you’re building an async application." — I
don't think similar in Django would hurt. /my view.

> ...as unwilling to support ...

Following the backport policy is not being unwilling to support.

Sorry (again) that I don't share your view. Sorry that undermines your
faith (in me) — I assume we still think there's room for rational
disagreement on how to weigh competing concerns in these kinds of cases.

I'm going to mute this thread until after the new year now.
Enjoy the festivities.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 11:34, James Bennett  wrote:

>
>
> On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson 
> wrote:
>
>> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that
>> means if you're using those on older versions of Django, you'll need to
>> work around.
>> This is no different than any of a thousand other cases where there's
>> been a bug in an older version that folks have needed to account for.
>>
>
> I believe it is very different and have explained why repeatedly.
>
> But if it is to be left unfixed, what is the plan for how to communicate
> the workaround to people who will be running into this bug until at least
> April of 2024? And what is the plan for communicating to them that Django
> is aware async testing is broken and the official policy is to knowingly
> leave it broken in every currently-released version of the framework? Even
> if it will not be fixed for older versions, Django 4.1 ought to be eligible
> for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
> though I do not know what could convince you at this point.
>
> This bug is bad. But this response to it is eroding my trust in Django,
> and I hope you know that is not something I say lightly. I think it also is
> going to erode the trust of other people when they find out about it, and
> is going to do so at a critical time when Django is facing stiff
> competition in the async space and cannot afford to lose more ground or be
> seen as unwilling to support its own claimed async features.
>
>> --
> 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/CAL13Cg_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com
>

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson 
wrote:

> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
> if you're using those on older versions of Django, you'll need to work
> around.
> This is no different than any of a thousand other cases where there's been
> a bug in an older version that folks have needed to account for.
>

I believe it is very different and have explained why repeatedly.

But if it is to be left unfixed, what is the plan for how to communicate
the workaround to people who will be running into this bug until at least
April of 2024? And what is the plan for communicating to them that Django
is aware async testing is broken and the official policy is to knowingly
leave it broken in every currently-released version of the framework? Even
if it will not be fixed for older versions, Django 4.1 ought to be eligible
for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
though I do not know what could convince you at this point.

This bug is bad. But this response to it is eroding my trust in Django, and
I hope you know that is not something I say lightly. I think it also is
going to erode the trust of other people when they find out about it, and
is going to do so at a critical time when Django is facing stiff
competition in the async space and cannot afford to lose more ground or be
seen as unwilling to support its own claimed async features.

>

-- 
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/CAL13Cg_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com.

Re: Backport for ticket 34063?

James,

I think the backport policy has proven itself over the years, no?

"Django lied" — that's a bit melodramatic don't you think?.
Django introduced a new feature, as it is wont to do.
There was a bug in that new feature, as there are wont to be.
Unfortunately that bug was not discovered during the timeframe in which it
would qualify for a backport.
However it's fixed in the upcoming version, which will be in pre-release in
just a couple of weeks.
Sorry for the inconvenience, but backport and supported versions policy is
the foundation of the stability and ease of update you've come to
appreciate in Django over all these years.

> This is a showstopper of a bug...

No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
if you're using those on older versions of Django, you'll need to work
around.
This is no different than any of a thousand other cases where there's been
a bug in an older version that folks have needed to account for.

> Unless another major bug gets found...

I'm *quite certain* there are plenty more of these to be found.
The journey is still really only just beginning.
I'd guess I'd say we're entering a new phase, but the async support is
neither complete nor mature.
There will be bugs.

I'm -1 on making an exception to the backport policy in this case. (Sorry I
don't agree with you.)

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 10:38, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson 
> wrote:
> > It's frustrating when this happens, but the backport policy has proven
> its worth time and again.
> > I **really** don't see the case for making an exception here.
> > (The policy has more value than the inconvenience in any of these cases,
> or even all of them summed.)
>
> I don't see the value here.
>
> If it's left as-is, the message is, effectively, that Django lied
> about its async support for years, but suddenly *now* is asking people
> to trust the claims of async support. Unless another major bug gets
> found, in which case "well, *now* you can trust Django on async" will
> get kicked down the road again.
>
> This is a showstopper of a bug, and just leaving it deliberately
> unfixed in *every released version of Django* because "policy said no"
> has the potential to do a lot of damage to Django's reputation.
>
> > Adding the support here is difficult and slow enough. Backporting fixes
> to discovered bugs, outside the established policy, is making an
> unrealistic burden for ourselves.
>
> I'm not saying every bug found with async needs a backport. But one
> that literally prevents the built-in testing tool from working with a
> huge swathe of views and middlewares (including potentially some built
> in to Django itself), *when that tool is documented and Django claims
> to officially support it*, is just unacceptable. I'll work up the
> patches myself if that's what it takes.
>
> --
> 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/CAL13Cg-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com
> .
>

-- 
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/CAJwKpyQdcKve7rx2fwscf-WTY5c2SzgtaCJeOC66hAbTiMd3dw%40mail.gmail.com.

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson  wrote:
> It's frustrating when this happens, but the backport policy has proven its 
> worth time and again.
> I **really** don't see the case for making an exception here.
> (The policy has more value than the inconvenience in any of these cases, or 
> even all of them summed.)

I don't see the value here.

If it's left as-is, the message is, effectively, that Django lied
about its async support for years, but suddenly *now* is asking people
to trust the claims of async support. Unless another major bug gets
found, in which case "well, *now* you can trust Django on async" will
get kicked down the road again.

This is a showstopper of a bug, and just leaving it deliberately
unfixed in *every released version of Django* because "policy said no"
has the potential to do a lot of damage to Django's reputation.

> Adding the support here is difficult and slow enough. Backporting fixes to 
> discovered bugs, outside the established policy, is making an unrealistic 
> burden for ourselves.

I'm not saying every bug found with async needs a backport. But one
that literally prevents the built-in testing tool from working with a
huge swathe of views and middlewares (including potentially some built
in to Django itself), *when that tool is documented and Django claims
to officially support it*, is just unacceptable. I'll work up the
patches myself if that's what it takes.

-- 
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/CAL13Cg-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com.

Re: Backport for ticket 34063?

OK, yes, that's probably right.

Had #34063 been reported during the 3.1 cycle it would have been a release
blocker.
As it was, it wasn't reported until 4.0 (when main was already 4.1) so two
cycles later.
As such it no longer qualifies for a backport.

It's frustrating when this happens, but the backport policy has proven its
worth time and again.
I **really** don't see the case for making an exception here.
(The policy has more value than the inconvenience in any of these cases, or
even all of them summed.)

> As it was, it wasn't reported until 4.0 ...

I think the bottomline is people are only starting to use this stuff now.
It's still experimental, for whatever that means, and there simply are and
will be rough edges.
I'd be very happy to think about how we should message that better — a big
sign saying "Still in development: if you want to use async, be on the
latest versions" would be fine in my opinion.
I think we've been pretty upfront that that's the case.
Adding the support here is difficult and slow enough. Backporting fixes to
discovered bugs, outside the established policy, is making an unrealistic
burden for ourselves.

On Fri, 30 Dec 2022 at 10:13, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson 
> wrote:
> > All you're talking about is adding this to your test cases right?
> >
> > # Work around Django #34063 until 4.2.
> > request.body
>
> As far as I can tell it needs to go in whatever code will *read*
> request.POST, not the code that generates the request. So that means a
> no-op "request.body" in every view and every middleware that might
> read request.POST. And that includes Django's own built-in views
> (including generic views) and any built-in async-supporting
> middlewares, if they have the misfortune to get called on the async
> path from an AsyncClient-initiated request.
>
> --
> 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/CAL13Cg_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%40mail.gmail.com
> .
>

-- 
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/CAJwKpyTCeMvXsxHwENYf0pEw2ySBXOadBEe_EXC04SndSk%3D6bQ%40mail.gmail.com.

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson  wrote:
> All you're talking about is adding this to your test cases right?
>
> # Work around Django #34063 until 4.2.
> request.body

As far as I can tell it needs to go in whatever code will *read*
request.POST, not the code that generates the request. So that means a
no-op "request.body" in every view and every middleware that might
read request.POST. And that includes Django's own built-in views
(including generic views) and any built-in async-supporting
middlewares, if they have the misfortune to get called on the async
path from an AsyncClient-initiated request.

-- 
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/CAL13Cg_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%40mail.gmail.com.

Re: Backport for ticket 34063?

James,

All you're talking about is adding this to your test cases right?

# Work around Django #34063 until 4.2.
request.body

# ... continue


C.

On Fri, 30 Dec 2022 at 10:04, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
>  wrote:
> > When I looked at the trace you posted in IRC yesterday, my first thought
> was "3.2?". I think supporting Django 3.2 at this point isn't worth the
> effort.
>
> It's also broken in 4.0 and 4.1. I just posted the first trace I got
> back from my test matrix, which happened to be a Django 3.2 run.
>
> > Yes, sure it's not EOL for another year or so but if folks want to use
> async they should be on the latest version.
>
> I strongly disagree with this -- Django has been claiming support for
> async views/middlewares, and for testing them with AsyncClient, since
> 3.1. Telling people that actually it was badly broken to the point of
> almost unusability until 4.2 and thus not to use any of those versions
> that claimed to have the support is... suboptimal. Especially given,
> as I noted, the difficulty for Django novices of even figuring out
> what the heck is going on when they try to test an async view and get
> a weird exception.
>
> Or to put it another way: if I submitted patches against the 3.2, 4.0,
> and 4.1 branches for docs/topics/testing/tools.txt that put a big
> "WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
> those patches would be well-received. But that's basically what those
> releases of Django *need* at this point. It's intolerably misleading
> to end users of the framework to have docs for those versions claiming
> that you can write async code and test it with the AsyncClient when...
> well, you can't, really, unless you know the precise way that it's
> broken and put explicit workarounds for the brokenness in all your
> views and middlewares.
>
> > You're wanting to add async support to your third-party library: super;
> just say it's 4.2+ and move on.
>
> And telling library authors not to even think about doing async
> support until Django 4.2 comes out (approximately two and a half years
> after Django itself claimed to officially support this stuff), and
> that they have to cut off all older versions of Django when they do so
> *despite those versions officially claiming to support async* just
> seems like a recipe for those authors deciding not to trust or waste
> their time on Django.
>
> So I *really* think this one needs an exception to the backports
> policy. Async is too important, and Django's reputation is too
> important, to leave 3.2, 4.0, and 4.1 as badly broken as they
> currently are.
>
> --
> 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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%40mail.gmail.com
> .
>

-- 
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/CAJwKpyQzd%2BUBKWECbHwZvZ37zRRwYh4w9LAMsZFMzqLPvTM5cA%40mail.gmail.com.

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
 wrote:
> When I looked at the trace you posted in IRC yesterday, my first thought was 
> "3.2?". I think supporting Django 3.2 at this point isn't worth the effort.

It's also broken in 4.0 and 4.1. I just posted the first trace I got
back from my test matrix, which happened to be a Django 3.2 run.

> Yes, sure it's not EOL for another year or so but if folks want to use async 
> they should be on the latest version.

I strongly disagree with this -- Django has been claiming support for
async views/middlewares, and for testing them with AsyncClient, since
3.1. Telling people that actually it was badly broken to the point of
almost unusability until 4.2 and thus not to use any of those versions
that claimed to have the support is... suboptimal. Especially given,
as I noted, the difficulty for Django novices of even figuring out
what the heck is going on when they try to test an async view and get
a weird exception.

Or to put it another way: if I submitted patches against the 3.2, 4.0,
and 4.1 branches for docs/topics/testing/tools.txt that put a big
"WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
those patches would be well-received. But that's basically what those
releases of Django *need* at this point. It's intolerably misleading
to end users of the framework to have docs for those versions claiming
that you can write async code and test it with the AsyncClient when...
well, you can't, really, unless you know the precise way that it's
broken and put explicit workarounds for the brokenness in all your
views and middlewares.

> You're wanting to add async support to your third-party library: super; just 
> say it's 4.2+ and move on.

And telling library authors not to even think about doing async
support until Django 4.2 comes out (approximately two and a half years
after Django itself claimed to officially support this stuff), and
that they have to cut off all older versions of Django when they do so
*despite those versions officially claiming to support async* just
seems like a recipe for those authors deciding not to trust or waste
their time on Django.

So I *really* think this one needs an exception to the backports
policy. Async is too important, and Django's reputation is too
important, to leave 3.2, 4.0, and 4.1 as badly broken as they
currently are.

-- 
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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-29 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Hey James.

Grrr. 

I don't think this justifies an exception to the backport policy. It's not
significantly different from any of any number of other fixes that folks
ask for a backport for and we say no. Fielding "but you backported that
one" isn't an extra task that's going to be helpful.

When I looked at the trace you posted in IRC yesterday, my first thought
was "3.2?". I think supporting Django 3.2 at this point isn't worth
the effort.
Yes, sure it's not EOL for another year or so but if folks want to use
async they should be on the latest version.
There's significant changes still in each version, and sticking on the old
LTS is asking for trouble. (I certainly don't see making exceptions to the
backport policy to help out such to be a good idea. The old LTS is for
frozen apps, not new development.)
You're wanting to add async support to your third-party library: super;
just say it's 4.2+ and move on.
Folks who aren't on the LTS will be updating shortly enough anyway. A
little-bit of carrot never hurt.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 01:44, James Bennett  wrote:

> https://code.djangoproject.com/ticket/34063
>
> The short summary of that ticket is that there was a significant
> behavioral difference between django.test.Client and
> django.test.AsyncClient: with AsyncClient, any view or middleware
> which attempted to access request.POST without first accessing
> request.body would raise an exception with an obscure message about
> trying to read too much data from the request body. This was fixed
> last month:
>
>
> https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2
>
> However, it does not explicitly fall under any of the criteria for
> backporting to older releases
> (
> https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions
> )
> so at the moment, the fix will only be available from Django 4.2
> onward, and no previous Django versions will receive a backported
> version of the fix (though the bug is present back to at least Django
> 3.2, and I suspect but haven't confirmed all the way back to the
> introduction of AsyncClient in Django 3.1).
>
> I'd like to argue for an exception to the normal backport policy, and
> for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS.
>
> My reasoning here is that async support is an incredibly important
> part of the Python web ecosystem right now, and there is no good
> alternative to django.test.AsyncClient for testing some kinds of async
> code -- although the normal django.test.Client can hit URLs served by
> async views, it does not always trigger async code paths inside Django
> when doing so. For example, I came across #34063 while trying to test
> a middleware that supports both sync and async usage; only AsyncClient
> reliably exercises the async code path of such a middleware, but that
> triggers the bug unless I add throwaway accesses of request.body.
>
> Especially for authors of reusable applications/libraries that try to
> support a broad range of Django versions, many of whom (like me!) are
> finally getting around to async support, this is an unpleasant
> situation, since it will require the request.body workaround to be
> left in place in all such code for at least another 16 months or so
> (which is when Django 3.2 LTS will finally drop out of upstream
> support). And that's presuming such authors even know to put in the
> workaround -- it took me quite a bit of debugging and following up on
> irrelevant search results before I finally found #34063, and that's as
> someone who has deep familiarity with Django -- someone less
> experienced at delving into Django's internals to figure out root
> causes and likely search terms would probably have had an even worse
> time of it.
>
> Finally, if it had been discovered prior to any of the releases in
> which AsyncClient has been present, this would have been a clear
> release blocker; it's quite a serious bug that seems to have gone
> unnoticed for so long largely by accident (and, ironically, by
> under-testing of the testing tools).
>
> So I think the right thing to do, to help with Django's transition
> into async support and to avoid imposing unnecessary burdens of
> debugging on application and library authors, is to backport the fix
> from #34063 to the full set of currently-supported Django releases:
> 4.1, 4.0, and 3.2 LTS.
>
> --
> 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/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To

Backport for ticket 34063?

2022-12-29 Thread James Bennett

https://code.djangoproject.com/ticket/34063

The short summary of that ticket is that there was a significant
behavioral difference between django.test.Client and
django.test.AsyncClient: with AsyncClient, any view or middleware
which attempted to access request.POST without first accessing
request.body would raise an exception with an obscure message about
trying to read too much data from the request body. This was fixed
last month:

https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2

However, it does not explicitly fall under any of the criteria for
backporting to older releases
(https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions)
so at the moment, the fix will only be available from Django 4.2
onward, and no previous Django versions will receive a backported
version of the fix (though the bug is present back to at least Django
3.2, and I suspect but haven't confirmed all the way back to the
introduction of AsyncClient in Django 3.1).

I'd like to argue for an exception to the normal backport policy, and
for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS.

My reasoning here is that async support is an incredibly important
part of the Python web ecosystem right now, and there is no good
alternative to django.test.AsyncClient for testing some kinds of async
code -- although the normal django.test.Client can hit URLs served by
async views, it does not always trigger async code paths inside Django
when doing so. For example, I came across #34063 while trying to test
a middleware that supports both sync and async usage; only AsyncClient
reliably exercises the async code path of such a middleware, but that
triggers the bug unless I add throwaway accesses of request.body.

Especially for authors of reusable applications/libraries that try to
support a broad range of Django versions, many of whom (like me!) are
finally getting around to async support, this is an unpleasant
situation, since it will require the request.body workaround to be
left in place in all such code for at least another 16 months or so
(which is when Django 3.2 LTS will finally drop out of upstream
support). And that's presuming such authors even know to put in the
workaround -- it took me quite a bit of debugging and following up on
irrelevant search results before I finally found #34063, and that's as
someone who has deep familiarity with Django -- someone less
experienced at delving into Django's internals to figure out root
causes and likely search terms would probably have had an even worse
time of it.

Finally, if it had been discovered prior to any of the releases in
which AsyncClient has been present, this would have been a clear
release blocker; it's quite a serious bug that seems to have gone
unnoticed for so long largely by accident (and, ironically, by
under-testing of the testing tools).

So I think the right thing to do, to help with Django's transition
into async support and to avoid imposing unnecessary burdens of
debugging on application and library authors, is to backport the fix
from #34063 to the full set of currently-supported Django releases:
4.1, 4.0, and 3.2 LTS.

-- 
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/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com.

Re: Updating profile image in django

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Mon, Dec 26, 2022 at 4:32 PM Nsikan Patrick 
wrote:

> Hello everyone, so I have I have this issue when trying to update a
> profile photo in django.
> The Profile photo actually updates if I upload an image. But there are
> cases where a user may want to update other details without updating the
> profile photo.
> Trying to implement that gives me a multivalue error.
> I've been on this for some time now, who knows how I can handle that.
> Here's my code on views.py file
>
> def profile_update(request, user_id):
> if request.method == 'POST':
> user_obj = User.objects.get(id=user_id)
> user_profile_obj = UserProfile.objects.get(user=user_id)
>
> user_img = request.FILES['user_img']
> username = request.POST["username"]
> email = request.POST["email"]
> phone = request.POST["phone"]
> address = request.POST["address"]
>
> fs_handle = FileSystemStorage()
> img_name = 'uploads/profile_pictures/user_{0}'.format(user_id)
> if fs_handle.exists(img_name):
> fs_handle.delete(img_name)
> fs_handle.save(img_name, user_img)
>
> user_profile_obj.profile_pic = img_name
>
> user_profile_obj.phone = phone
> user_profile_obj.address = address
> user_profile_obj.save()
>
> user_obj.username =  username
> user_obj.email = email
> user_obj.save()
> user_obj.refresh_from_db()
>
> --
> 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/ad3f98d1-c715-41e0-b05e-99e8be1f856cn%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM0RuXhd5eR-hFmEtcwm9kesV8HCUPzJ27-GdgYbtMaRAg%40mail.gmail.com.

Re: building a payment app

2022-12-28 Thread Ferran Jovell

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Ferran

Missatge de Music Fm  del dia dc., 28 de des. 2022 a les
20:23:

> hi everyone, thank your for accepting me.
> so i am building a payment gateway and i am stuck on how to integrate the
> cards in the views in django. can anyone help me
>
> --
> 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/34486f46-fa16-40fd-b356-97b82f2f379en%40googlegroups.com
> 
> .
>

-- 
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/CAEKh-sndApxo4wHPXUJB1cG5hn3pEGJjugUWDyfZb%3DJ4P0ocnw%40mail.gmail.com.

building a payment app

2022-12-28 Thread Music Fm

hi everyone, thank your for accepting me.
so i am building a payment gateway and i am stuck on how to integrate the 
cards in the views in django. can anyone help me

-- 
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/34486f46-fa16-40fd-b356-97b82f2f379en%40googlegroups.com.

Re: Fellow Reports - December 2022

2022-12-28 Thread Mariusz Felisiak

Week ending December 25, 2022

*Triaged: *
https://code.djangoproject.com/ticket/34217 - Migration removing a
CheckConstraint results in ProgrammingError using MySQL < 8.0.16.
(accepted)
https://code.djangoproject.com/ticket/34216 - django admin when field is
autocomplete it overrides ModelForm filter (invalid)
https://code.djangoproject.com/ticket/34218 - Password mismatch on
UserCreationForm not translated to the Slovenian language (invalid)
https://code.djangoproject.com/ticket/34219 - Collation is not preserved
when field is altered on PostgreSQL and MySQL. (accepted)
https://code.djangoproject.com/ticket/34220 - Cannot import
csrf_input_lazy from partially initialized module. (accepted)
https://code.djangoproject.com/ticket/34223 - I am Faceing tis type of
error when i run the command py manage.py runserver Error=usage: manage.py
[-h] [-c] manage.py: error: unrecognized arguments: runserver (invalid)
https://code.djangoproject.com/ticket/34225 - bulk_create() raises
IntegrityError when another constraint exists on set of fields. (invalid)
https://code.djangoproject.com/ticket/34226 - QuerySet.select_related()
with multiple filtered relations to the OneToOneField sets the last one.
(accepted)
https://code.djangoproject.com/ticket/34224 - App name in help text of
commands is missing context (wontfix)

*Reviewed/committed: *
https://github.com/django/django/pull/16369 - Fixed #33662 -- Allowed
Sitemap to customize languages for each item.
https://github.com/django/django/pull/16380 - Refs #34118 -- Adopted
asgiref coroutine detection shims.
https://github.com/django/django/pull/16400 - Fixed #34165 -- Made
permissions creation respect the "using" parameter.

*Reviewed: *
https://github.com/django/django/pull/16384 - Fixed #33735 -- Added
async support to StreamingHttpResponse.

*Authored: *
https://github.com/django/django/pull/16394 - [4.1.x] Updated
translations from Transifex.
https://github.com/django/django/pull/16396 - Fixed #34219 -- Preserved
Char/TextField.db_collation when altering column type.
https://github.com/django/django/pull/16402 - Refs #34226 -- Renamed
local field variables in SQLCompiler.get_related_selections() to avoid
redefinition.

Best,
Mariusz

Updating profile image in django

2022-12-26 Thread Nsikan Patrick

Hello everyone, so I have I have this issue when trying to update a profile 
photo in django.
The Profile photo actually updates if I upload an image. But there are 
cases where a user may want to update other details without updating the 
profile photo.
Trying to implement that gives me a multivalue error.
I've been on this for some time now, who knows how I can handle that.
Here's my code on views.py file

def profile_update(request, user_id):
if request.method == 'POST':
user_obj = User.objects.get(id=user_id)
user_profile_obj = UserProfile.objects.get(user=user_id)

user_img = request.FILES['user_img']
username = request.POST["username"]
email = request.POST["email"]
phone = request.POST["phone"]
address = request.POST["address"]

fs_handle = FileSystemStorage()
img_name = 'uploads/profile_pictures/user_{0}'.format(user_id)
if fs_handle.exists(img_name):
fs_handle.delete(img_name)
fs_handle.save(img_name, user_img)

user_profile_obj.profile_pic = img_name

user_profile_obj.phone = phone
user_profile_obj.address = address
user_profile_obj.save()

user_obj.username =  username
user_obj.email = email
user_obj.save()
user_obj.refresh_from_db()

-- 
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/ad3f98d1-c715-41e0-b05e-99e8be1f856cn%40googlegroups.com.

Re: django squashmigrations creating incorrect code?

2022-12-26 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Yes, a single line message warning that the migration needs some edits
would be nice.

On Fri, Dec 23, 2022 at 11:18 AM Christian González <
christian.gonza...@nerdocs.at> wrote:

> HM wouldn't it be better to add a stdout message after completing the
> squash? Because if the cmd doesn't say anything, the user assumes that
> everything went well. I wasn't aware of squash migrations being even that
> smart to recognise RunPython methods.
> So a stdout.write() with more or less this message would help a lot.
> Christian
>
> --
> 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/207a3a0c-853c-4d8d-bc17-d7da1c2d6953%40nerdocs.at
> 
> .
>

-- 
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/CAMyDDM3Bkj%3D3Rd%2BQYY3gEL7tz8GOX6cPE4p34YsV4U6%3DPMPsLw%40mail.gmail.com.

Re: Generated Field

2022-12-24 Thread 'schinckel' via Django developers (Contributions to Django itself)

I believe there are a bunch of similarities between the requirements of 
generated fields and my project 
django-shared-property: https://django-shared-property.readthedocs.io/en/latest/

On Sunday, December 25, 2022 at 10:23:10 AM UTC+10:30 jeremy...@gmail.com 
wrote:

> I'd love to help implement this if we can find a rough syntax! I've made a 
> proof of concept in Postgres, and there are two outstanding limitations to 
> address:
>
> - The generated field value is not set until the model is reloaded from 
> the database
> - The `GENERATED ALWAYS` expression requires an argument to be injected in 
> the the sql expression, but this is not currently possible
>
> *from django.db.backends.utils import CursorWrapper*
>
> *from django.db.models import Expression, Field*
>
> *from django.db.models.sql import Query*
>
>
>
> *class GeneratedField(Field):*
>
> *"""*
>
> *Wrapper field used to support generated columns in postgres.*
>
> *"""*
>
>
> *def __init__(self, expression: Expression, db_collation: str = None, 
> *args, **kwargs):*
>
> *"""*
>
> *:param expression: DB expression used to calculate the 
> auto-generated field value*
>
> *"""*
>
>
> *self.expression = expression*
>
> *self.db_collation = db_collation*
>
>
> *kwargs['editable'] = False  # This field can never be edited*
>
> *kwargs['blank'] = True  # This field never requires a value to be 
> set*
>
> *kwargs['null'] = True  # This field never requires a value to be 
> set*
>
>
> *super().__init__(*args, **kwargs)*
>
>
> *def _compile_expression(self, cursor: CursorWrapper, sql: str, 
> params: dict):*
>
> *"""*
>
> *Compiles SQL and its associated parameters into a full SQL query. 
> Usually sql params are kept*
>
> *separate until `cursor.execute()` is called, but this is not 
> possible since this function*
>
> *must return a single sql string.*
>
> *"""*
>
>
> *return cursor.mogrify(sql, params).decode()*
>
>
> *def db_type(self, connection):*
>
> *"""*
>
> *Called when calculating SQL to create DB column (e.g. DB 
> migrations)*
>
> *
> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.db_type
>  
> *
>
> *"""*
>
>
> *db_type = 
> self.expression.output_field.db_type(connection=connection)*
>
>
> *# Convert any F() references to concrete field names*
>
> *query = Query(model=self.model, alias_cols=False)*
>
> *expression = self.expression.resolve_expression(query, 
> allow_joins=False)*
>
>
> *# Compile expression into SQL*
>
> *expression_sql, params = expression.as_sql(*
>
> *compiler=connection.ops.compiler('SQLCompiler')(*
>
> *query, connection=connection, using=None*
>
> *),*
>
> *connection=connection,*
>
> *)*
>
>
> *with connection.cursor() as cursor:*
>
> *expression_sql = self._compile_expression(*
>
> *cursor=cursor, sql=expression_sql, params=params*
>
> *)*
>
>
> *return f'{db_type} GENERATED ALWAYS AS ({expression_sql}) STORED'*
>
>
> *def rel_db_type(self, connection):*
>
> *"""*
>
> *Called when calculating SQL to reference DB column*
>
> *
> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.rel_db_type
>  
> *
>
> *"""*
>
> *return 
> self.expression.output_field.db_type(connection=connection)*
>
>
> *def deconstruct(self):*
>
> *"""*
>
> *Add custom field properties to allow migrations to deconstruct 
> field*
>
> *
> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.deconstruct
>  
> *
>
> *"""*
>
> *name, path, args, kwargs = super().deconstruct()*
>
> *kwargs['expression'] = self.expression*
>
> *if self.db_collation is not None:*
>
> *kwargs['db_collation'] = self.db_collation*
>
> *return name, path, args, kwargs*
>
>
>
> *class GeneratedFieldQuerysetMixin:*
>
> *"""*
>
> *Must be added to queryset classes*
>
> *"""*
>
>
> *def _insert(self, objs, fields, *args, **kwargs):*
>
> *if getattr(self.model, '_generated_fields', None) and fields:*
>
> *# Don't include generated fields when performing a 
> `model.objects.bulk_create()`*
>
> *fields = [f for f in fields if f not in 
> self.model._generated_fields()]*
>
>
> *return super()._insert(objs, fields, *args, **kwargs)*
>
>
>
> *class GeneratedFieldModelMixin:*
>
> *"""*
>
> *Must be added

Re: Generated Field

2022-12-24 Thread Jeremy Nauta

I'd love to help implement this if we can find a rough syntax! I've made a 
proof of concept in Postgres, and there are two outstanding limitations to 
address:

- The generated field value is not set until the model is reloaded from the 
database
- The `GENERATED ALWAYS` expression requires an argument to be injected in 
the the sql expression, but this is not currently possible

*from django.db.backends.utils import CursorWrapper*

*from django.db.models import Expression, Field*

*from django.db.models.sql import Query*



*class GeneratedField(Field):*

*"""*

*Wrapper field used to support generated columns in postgres.*

*"""*


*def __init__(self, expression: Expression, db_collation: str = None, 
*args, **kwargs):*

*"""*

*:param expression: DB expression used to calculate the 
auto-generated field value*

*"""*


*self.expression = expression*

*self.db_collation = db_collation*


*kwargs['editable'] = False  # This field can never be edited*

*kwargs['blank'] = True  # This field never requires a value to be 
set*

*kwargs['null'] = True  # This field never requires a value to be 
set*


*super().__init__(*args, **kwargs)*


*def _compile_expression(self, cursor: CursorWrapper, sql: str, params: 
dict):*

*"""*

*Compiles SQL and its associated parameters into a full SQL query. 
Usually sql params are kept*

*separate until `cursor.execute()` is called, but this is not 
possible since this function*

*must return a single sql string.*

*"""*


*return cursor.mogrify(sql, params).decode()*


*def db_type(self, connection):*

*"""*

*Called when calculating SQL to create DB column (e.g. DB 
migrations)*

*
https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.db_type*

*"""*


*db_type = 
self.expression.output_field.db_type(connection=connection)*


*# Convert any F() references to concrete field names*

*query = Query(model=self.model, alias_cols=False)*

*expression = self.expression.resolve_expression(query, 
allow_joins=False)*


*# Compile expression into SQL*

*expression_sql, params = expression.as_sql(*

*compiler=connection.ops.compiler('SQLCompiler')(*

*query, connection=connection, using=None*

*),*

*connection=connection,*

*)*


*with connection.cursor() as cursor:*

*expression_sql = self._compile_expression(*

*cursor=cursor, sql=expression_sql, params=params*

*)*


*return f'{db_type} GENERATED ALWAYS AS ({expression_sql}) STORED'*


*def rel_db_type(self, connection):*

*"""*

*Called when calculating SQL to reference DB column*

*
https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.rel_db_type*

*"""*

*return self.expression.output_field.db_type(connection=connection)*


*def deconstruct(self):*

*"""*

*Add custom field properties to allow migrations to deconstruct 
field*

*
https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.deconstruct*

*"""*

*name, path, args, kwargs = super().deconstruct()*

*kwargs['expression'] = self.expression*

*if self.db_collation is not None:*

*kwargs['db_collation'] = self.db_collation*

*return name, path, args, kwargs*



*class GeneratedFieldQuerysetMixin:*

*"""*

*Must be added to queryset classes*

*"""*


*def _insert(self, objs, fields, *args, **kwargs):*

*if getattr(self.model, '_generated_fields', None) and fields:*

*# Don't include generated fields when performing a 
`model.objects.bulk_create()`*

*fields = [f for f in fields if f not in 
self.model._generated_fields()]*


*return super()._insert(objs, fields, *args, **kwargs)*



*class GeneratedFieldModelMixin:*

*"""*

*Must be added to model class*

*"""*


*def _generated_fields(cls) -> list[Field]:*


*"""*

*:return all fields of the model that are generated*

*"""*


*return [*

*f*

*for f in cls._meta.fields*

*if isinstance(f, GeneratedField)*

*]*


*def _do_insert(self, manager, using, fields, *args, **kwargs):*

*generated_fields = self._generated_fields()*

*if generated_fields and fields:*

*# Don't include generated fields when performing a `save()` or 
`create()`*

*fields = [f for f in fields if f not in generated_fields]*


*return super()._do_insert(manager, using, fields, *args, **kwargs)*


*def _do_update(self, base_qs, using, pk_val, values, *args, **kwargs):*

*generated_fields = self._generated_fields()*

Re: django squashmigrations creating incorrect code?

2022-12-23 Thread Christian González

HM wouldn't it be better to add a stdout message after completing the squash? 
Because if the cmd doesn't say anything, the user assumes that everything went 
well. I wasn't aware of squash migrations being even that smart to recognise 
RunPython methods.
So a stdout.write() with more or less this message would help a lot.
Christian

-- 
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/207a3a0c-853c-4d8d-bc17-d7da1c2d6953%40nerdocs.at.

Re: django squashmigrations creating incorrect code?

2022-12-22 Thread Naresh Pahariya

Good to know.

On Fri, Dec 23, 2022, 02:43 Christian González <
christian.gonza...@nerdocs.at> wrote:

> AH, sorry. Just saw it:
>
> # Functions from the following migrations need manual copying.# Move them and 
> any dependencies into this file, then update the# RunPython operations to 
> refer to the local versions:# medux.core.migrations.0001_initial
>
>
> Am 22.12.22 um 22:12 schrieb Christian González:
>
> Hi devs,
>
> before I file a bug, small check here:
>
> I squashed my migrations using "./manage.py squashmigrations  core 0003"
>
> It squashed all existing 3 migrations, including a runPython migration in
> 0001.
>
> The resulting migration contains this code:
>
> migrations.RunPython(
> code=medux.core.migrations.0001_initial.create_admin_user,
> ),
>
> Which is not working, as Python complains:
>
> File
> "/home/christian/Projekte/medux/src/medux/core/migrations/0001_squashed_0003_alter_address_id_alter_addressmapper_id_and_more.py",
> line 57
> code=medux.core.migrations.0001_initial.create_admin_user,
>^
> SyntaxError: invalid decimal literal
>
> So I suppose that is not intended. Is this a django bug? Should I file
> this as issue?
>
> Cheers,
>
> Christian
>
>
> --
> Dr. Christian Gonzálezhttps://nerdocs.at
>
> --
> 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/286d7666-41eb-12ef-44b5-640993f480c3%40nerdocs.at
> 
> .
>
> --
> Dr. Christian Gonzálezhttps://nerdocs.at
>
> --
> 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/c38d379d-5253-d70b-9cff-6e4f31616a45%40nerdocs.at
> 
> .
>

-- 
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/CAMpxr5qsER_bAizPQtuU4CvhH5xQnxirsuh8%3DFeeKHruZ5rp-g%40mail.gmail.com.

Re: django squashmigrations creating incorrect code?

2022-12-22 Thread Christian González

AH, sorry. Just saw it:

# Functions from the following migrations need manual copying. # Move
them and any dependencies into this file, then update the # RunPython
operations to refer to the local versions: #
medux.core.migrations.0001_initial

Am 22.12.22 um 22:12 schrieb Christian González:

Hi devs,

before I file a bug, small check here:

I squashed my migrations using "./manage.py squashmigrations core 0003"

It squashed all existing 3 migrations, including a runPython migration
in 0001.

The resulting migration contains this code:

migrations.RunPython(
code=medux.core.migrations.0001_initial.create_admin_user,
),

Which is not working, as Python complains:

File

"/home/christian/Projekte/medux/src/medux/core/migrations/0001_squashed_0003_alter_address_id_alter_addressmapper_id_and_more.py",
line 57
code=medux.core.migrations.0001_initial.create_admin_user,
^
SyntaxError: invalid decimal literal

So I suppose that is not intended. Is this a django bug? Should I file
this as issue?

Cheers,

Christian

--
Dr. Christian González
https://nerdocs.at
--
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/286d7666-41eb-12ef-44b5-640993f480c3%40nerdocs.at
.

--
Dr. Christian González
https://nerdocs.at

--
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/c38d379d-5253-d70b-9cff-6e4f31616a45%40nerdocs.at.

django squashmigrations creating incorrect code?

2022-12-22 Thread Christian González


Hi devs,

before I file a bug, small check here:

I squashed my migrations using "./manage.py squashmigrations core 0003"

It squashed all existing 3 migrations, including a runPython migration 
in 0001.


The resulting migration contains this code:

   migrations.RunPython(
   code=medux.core.migrations.0001_initial.create_admin_user,
   ),

Which is not working, as Python complains:

   File
   
"/home/christian/Projekte/medux/src/medux/core/migrations/0001_squashed_0003_alter_address_id_alter_addressmapper_id_and_more.py",
   line 57
    code=medux.core.migrations.0001_initial.create_admin_user,
   ^
   SyntaxError: invalid decimal literal

So I suppose that is not intended. Is this a django bug? Should I file 
this as issue?


Cheers,

Christian


--
Dr. Christian González
https://nerdocs.at

--
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/286d7666-41eb-12ef-44b5-640993f480c3%40nerdocs.at.

Re: DEP 12 (Steering Council) Fully Adopted

2022-12-22 Thread mridul pandey

Awesome

On Mon, 19 Dec 2022 at 8:55 PM, Andrew Godwin  wrote:

> Hi everyone,
>
> I am pleased to report that we've completed the extended approval process
> for DEP 12, which was needed since it was a governance change. Both the
> Technical Board and the DSF Board voted to not require a vote from the
> membership on the change, so it is now officially adopted and I will begin
> implementation immediately (which is mostly going to be renaming things).
>
> Thanks everyone for your comments and help refining this DEP! You'll be
> hearing more from myself or one of the other Steering Council members soon
> about our first proper "call for feature proposals", as it'll be timed
> right after the 4.2 feature freeze in January.
>
>
> Andrew
>
> --
> 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/89537c96-377d-4e86-8a8e-5ef738576ea2%40app.fastmail.com
> 
> .
>

-- 
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/CAFZKv7up_Fs-8KYU5fVsAEczbHGY6dmjjW_QvkqsqpfeVQhNNg%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

2022-12-21 Thread Jörg Breitbart


> 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 thats also a good reason to "bake smaller buns" (german 
saying), and not trying to revamp too many things in one go. So how 
about doing this iteratively - fixing the DB url thing first (as there 
is prior art to learn from), and in a second step trying to deal with 
the cache settings?


Cheers,
Jörg

--
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/cf7661f1-cdf9-87cb-10fb-a58e1ed25edb%40netzkolchose.de.

Re: Potential way forward for DATABASE_URL

2022-12-20 Thread Raphael G

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

Re: Potential way forward for DATABASE_URL

2022-12-20 Thread Raphael G

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

get_manager short ut function proposal

2022-12-19 Thread Ramez Ashraf

Hello everyone, 

I want to propose a helper function
`get_manager(parent_manager=None, *args, **kwargs)` 

A shortcut to return a manager, *args & **kwargs are passed to the manager 
.filter()
pass parent_manager to customize the parent manager, defaults to 
``Manager``.

it can be used like this 

from django.db.models import get_manager

class Person(models.Model):
# ...
authors = models.get_manager(role='A')
editors = models.get_manager(role='E')
special = get_manager(~Q(name="Roald Dahl"), role='E')
manager_with_counts = get_manager(parent_manager=PollManager, 
name="Roald Dahl")

Instead of the current 

class AuthorManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(role='A')

class EditorManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(role='E')

class Person(models.Model):
people = models.Manager()
authors = AuthorManager()
editors = EditorManager()
   ...

The first is more readable and nicer .. yeah ?
Code is working and ready at  github 

 ,  

Do i get +1(s) to move forward and create a ticket ? 


-- 
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/f0e4367d-8a7e-48da-b78c-35036015212fn%40googlegroups.com.

DEP 12 (Steering Council) Fully Adopted

2022-12-19 Thread Andrew Godwin

Hi everyone,

I am pleased to report that we've completed the extended approval process for 
DEP 12, which was needed since it was a governance change. Both the Technical 
Board and the DSF Board voted to not require a vote from the membership on the 
change, so it is now officially adopted and I will begin implementation 
immediately (which is mostly going to be renaming things).

Thanks everyone for your comments and help refining this DEP! You'll be hearing 
more from myself or one of the other Steering Council members soon about our 
first proper "call for feature proposals", as it'll be timed right after the 
4.2 feature freeze in January.

Andrew

-- 
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/89537c96-377d-4e86-8a8e-5ef738576ea2%40app.fastmail.com.

Re: Fellow Reports - December 2022

2022-12-19 Thread Mariusz Felisiak

Week ending December 18, 2022

*Triaged: *
https://code.djangoproject.com/ticket/34204 - Django cannot load when
Python is compiled with --without-doc-strings enabled (wontfix)
https://code.djangoproject.com/ticket/34208 - Confirm/Add support for
GDAL 3.6. (created)
https://code.djangoproject.com/ticket/34209 - FileBasedCache has_key is
susceptible to race conditions (accepted)
https://code.djangoproject.com/ticket/34212 - Redis cache client uses a
read connection for incr operation (accepted)
https://code.djangoproject.com/ticket/34211 - Performance regression in
ForeignKeyDeferredAttribute changes. (accepted)
https://code.djangoproject.com/ticket/34213 - Update PostgreSQL package
names in docs (accepted)
https://code.djangoproject.com/ticket/34215 - Regression for
autocomplete_fields in admin (worksforme)
https://code.djangoproject.com/ticket/34214 - Bug in default for
TimeField when using a timezone (duplicate)

*Reviewed/committed: *
https://github.com/django/django/pull/16377 - Refs #33308 -- Moved
psycopg2 imports to the psycopg_any module and added new hooks.
https://github.com/django/django/pull/16374 - Made urls.py docstring
consistent with other files in project template.
https://github.com/django/django/pull/16378 - Fixed #34038 -- Improved
color contrast for links in admin.
https://github.com/django/django/pull/16379 - Fixed #34209 -- Prevented
FileBasedCache.has_key() crash caused by a race condition.
https://github.com/django/django/pull/16385 - Fixed #34213 -- Updated
PostgreSQL package names in installing PostGIS docs.
https://github.com/django/django/pull/15687 - Fixed #33308 -- Added
support for psycopg version 3.
https://github.com/django/django/pull/16386 - Fixed #34212 -- Made
RedisCacheClient.incr() use write connection.
https://github.com/django/django/pull/16311 - Fixed #34170 --
Implemented Heal The Breach (HTB) in GzipMiddleware.

*Authored: *
https://github.com/django/django/pull/16382 - Fixed #33961 -- Updated
admin's jQuery to 3.6.2.
https://github.com/django/django/pull/16383 - Removed KyngChaos packages
from docs.
https://github.com/django/django/pull/16387 - Fixed
lookup.tests.LookupTests.test_exact_none_transform() test on Oracle.

Best,
Mariusz

Fellow Reports - December 2022

2022-12-16 Thread Mariusz Felisiak

Week ending December 11, 2022

*Triaged: *
https://code.djangoproject.com/ticket/34200 - Allow setting postgres
role during connection setup (needsinfo)
https://code.djangoproject.com/ticket/34201 - Drop support for SQLite <
3.21.0 (created)
https://code.djangoproject.com/ticket/34202 - Strict time zone name
condition in PostgreSQL DatabaseWrapper. (wontfix)
https://code.djangoproject.com/ticket/34203 - Drop support for psycopg2
2.8 (wontfix)
https://code.djangoproject.com/ticket/34204 - Django cannot load when
Python is compiled with --without-doc-strings enabled (invalid)
https://code.djangoproject.com/ticket/34205 - Validation of constraints
with __len lookup crashes for ArrayFields. (accepted)
https://code.djangoproject.com/ticket/34206 - annotation of another
annotation duplicate query rule (invalid)

*Reviewed/committed: *
https://github.com/django/django/pull/16356 - Fixed #34199 -- Added
example to StringAgg docs.
https://github.com/django/django/pull/16354 - Improved test coverage for
django.db.transaction.
https://github.com/django/django/pull/16349 - Fixed #34194 -- Added
django.utils.http.content_disposition_header().
https://github.com/django/django/pull/16338 - Fixed #24048 -- Corrected
QuerySet.only() docs about interaction with defer().
https://github.com/django/django/pull/16357 - Fixed #29084 -- Skipped
some postgres_tests.test_search tests when pg_catalog isn't English.
https://github.com/django/django/pull/16362 - Refs #33308 -- Modernized
database wrapper in the PostgreSQL backend.
https://github.com/django/django/pull/16343 - Fixed #33199 -- Deprecated
passing positional arguments to Signer/TimestampSigner.
https://github.com/django/django/pull/16376 - Fixed #34205 -- Fixed
Meta.constraints validation crash with ArrayField and __len lookup.

*Authored: *
https://github.com/django/django/pull/16359 - Updated various links to
HTTPS and new locations.
https://github.com/django/django/pull/16361 - Fixed
AdminViewDeletedObjectsTest.test_cyclic failure when using --keepdb.
https://github.com/django/django/pull/16365 - Fixed contenttypes_tests
tests failures when using --keepdb.
https://github.com/django/django/pull/16366 - Fixed #34201 -- Bumped
minimum supported SQLite to 3.21.0.
https://github.com/django/django/pull/16368 - Made inspectdb used
Cursor.description.display_size for CharFields' max_length.
https://github.com/django/django/pull/16371 - Avoided direct mocking of
psycopg2.__version__ in test_correct_extraction_psycopg2_version().

Best,
Mariusz

--
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/eee2b733-e114-1720-9e75-0120667ae8b1%40gmail.com.

Re: Standalon Django ORM

2022-12-13 Thread Carlton Gibson

I think we already have this no?

See https://docs.djangoproject.com/en/4.1/ref/databases/#s-third-party-notes
for a list of 3rd party DB backends.

On Tue, 13 Dec 2022 at 10:31, Vasanth Mohan  wrote:

> I second Jörg about better maintainability with tighter integrations.
>
> However, for the fun of stirring the pot, what's the opinion on letting
> Django define an API for the ORM and letting a library deal with the
> DB-specific implementation that generates the SQL for query?  Django could
> have a list of officially supported DBs ('django.db.postgres') to be
> included in the INSTALLED_APPS to select the DB to be used.
>
> Meanwhile, the community can come up with support for other DBs like
> CockroachDB, Mongo etc. (just an idea borrowed off the rust community). It
> can even allow adding additional filters/commands specific to the DB.
>
> Vaz
>
> On Monday, 12 December 2022 at 13:07:50 UTC+1 j.bre...@netzkolchose.de
> wrote:
>
>> I tend to believe the opposite is true. Django was/is a successor in its
>> field, because it offers an "out-of-the-box" or "batteries included"
>> experience. Subsequently parts were shaped as needed for that bigger
>> picture, e.g. the ORM became what it is today.
>>
>> Does anyone still remember django versions with external south
>> migrations? Was much more tricky to get done right, ppl would just
>> forget it, do it in wrong order, whatsoever. Got basically fixed by the
>> tighter integration with typical django project lifecycling.
>>
>> By making the ORM an external lib with its own progression and
>> versioning you'd reintroduce all that fuzz again, plus frictions from
>> API changes, that seem logical from a db maintainer viewpoint, but make
>> life harder at consumer end (would be django here). By keeping it in one
>> place those tiny viewpoint differences can be leveled out upfront.
>>
>> Ofc mammoths move slower, but they are also more resilient against
>> disturbance. In terms of good long term maintainability the more
>> granular/agile approach as seen in the JS-world still has to prove
>> itself. Projects there need a lot more care of their dependency
>> lists, and typically wont run anymore after 1-2 years without manually
>> fixing this or that, because package xy of 100+ dependencies turned its
>> API upside-down for no good reason.
>>
>> So no, outsourcing things is not always a good idea.
>> All imho, ofc.
>>
>> Cheers,
>> Jörg
>>
> --
> 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/d405433e-3ce4-4737-9539-47012a405b9en%40googlegroups.com
> 
> .
>

-- 
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/CAJwKpyRrS%2BMztj%3DY57g%2BKcf%3D9%2B94PKDHtq7EimvSzxSvbdgVPA%40mail.gmail.com.

Re: Standalon Django ORM

2022-12-13 Thread Vasanth Mohan

I second Jörg about better maintainability with tighter integrations.

However, for the fun of stirring the pot, what's the opinion on letting 
Django define an API for the ORM and letting a library deal with the 
DB-specific implementation that generates the SQL for query?  Django could 
have a list of officially supported DBs ('django.db.postgres') to be 
included in the INSTALLED_APPS to select the DB to be used.

Meanwhile, the community can come up with support for other DBs like 
CockroachDB, Mongo etc. (just an idea borrowed off the rust community). It 
can even allow adding additional filters/commands specific to the DB.

Vaz

On Monday, 12 December 2022 at 13:07:50 UTC+1 j.bre...@netzkolchose.de 
wrote:

> I tend to believe the opposite is true. Django was/is a successor in its 
> field, because it offers an "out-of-the-box" or "batteries included" 
> experience. Subsequently parts were shaped as needed for that bigger 
> picture, e.g. the ORM became what it is today.
>
> Does anyone still remember django versions with external south 
> migrations? Was much more tricky to get done right, ppl would just 
> forget it, do it in wrong order, whatsoever. Got basically fixed by the 
> tighter integration with typical django project lifecycling.
>
> By making the ORM an external lib with its own progression and 
> versioning you'd reintroduce all that fuzz again, plus frictions from 
> API changes, that seem logical from a db maintainer viewpoint, but make 
> life harder at consumer end (would be django here). By keeping it in one 
> place those tiny viewpoint differences can be leveled out upfront.
>
> Ofc mammoths move slower, but they are also more resilient against 
> disturbance. In terms of good long term maintainability the more 
> granular/agile approach as seen in the JS-world still has to prove 
> itself. Projects there need a lot more care of their dependency 
> lists, and typically wont run anymore after 1-2 years without manually 
> fixing this or that, because package xy of 100+ dependencies turned its 
> API upside-down for no good reason.
>
> So no, outsourcing things is not always a good idea.
> All imho, ofc.
>
> Cheers,
> Jörg
>

-- 
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/d405433e-3ce4-4737-9539-47012a405b9en%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-12-12 Thread Mehfooz Shayan

Hi Developers, I am a Junior Python / Django Developer. I have developed
some projects with help of Django Backend Development with
complete authentication & authorization and others features.

So now my question is that, I am also learning Flutter in my university
course (Mobile Application Development - Flutter), so can I deploy my ML,
AI model with the help of Django as a Backend and FrontEnd of Mobile
application in Flutter ???

It will be easy or difficult to connect Django + Flutter for AI, ML models?
Any youtube channel or suggestion where i can covers these things so i can
develop my projects.

Thanks

On Tue, Nov 15, 2022 at 2:11 PM Carlton Gibson 
wrote:

> Hi all.
>
> Google Summer of Code (GSoC) for 2023 has just been announced.
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent
> successes include:
>
> * The django-stubs mypy plugin.
> * The cross-db JSON field.
> * The Redis cache backend.
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project.
> * ...
>
> Application deadline for Orgs is February 7. I'll begin working on it
> after the New Year.
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a
> Good Ideas List
> section.
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
> complete.
>
> i.e. "short" or "long" projects.
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*.
>
> I put "Technical Board?" in the subject because we're short a list of
> project
> ideas for the technical direction of Django going forward, and maybe
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because
> that's not
> meant to exclude other input.
>
> Here's last year's list for reference:
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and
> per-instance
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent
> agreement on scope,
>   so it's better to live as a third-party package.
>
> - I've tried to include folks from the wider ecosystem in previous years.
> Two years ago
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
> 
> .
>

-- 
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/CAH5CCcUABMmY%3D%3DqVyoMz6qpawFNa-heus%2BYOko9jb6C18z4PJA%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-12-12 Thread Ryan Cheley

Perhaps one of the ideas for GSoC would be to update the code for the ORM 
(or maybe just a single backend?) to include Type hints. Last year (2022) 
it was mentioned here 
.

I think this might make it easier to allow newcomers to try work Trac 
Tickets. When I was working ticket 10070 
 I found myself (on more than 
one occasion) asking, what is this going to return? I was able to hack my 
way through it, but it would have been nice (potentially) have had had 
types in there!

I know that there was a discussion on the Developers list here 
 and here 
 and a proposed 
DEP  that was closed ... the idea 
seems to be more of a 'wait and see'. 

I believe Carlton also referenced the idea of type hints in a couple of 
episodes of Django Chat (e103 with Nikita Sobolev and e105 with Adam 
Johnson)

Current ticket in trac is 29299 


Cheers,

Ryan

On Tuesday, November 29, 2022 at 1:40:41 PM UTC-8 charettes wrote:

> Adrian,
>
> > I'd personally like to see better support for safe / N-1 compatible 
> migrations within Django itself, currently if you do CD / blue-green tower 
> / etc. deployments you need to be very careful about the migration 
> operations that you introduce version-to-version, although I'm not sure 
> what that would look like.
>
> There's a little project that we use at $WORK to do just that[0]. I'm not 
> sure its inclusion in core is even proposable at this time as is still has 
> received very little feedback from external users but the gist of the tool 
> is that it introduces a notion of phases to migrations (pre and 
> post-deployment) and augments the `makemigrations` command so it splits 
> operations that require multiple phases in multiple migrations and adds a 
> `--pre-deploy` 
> flag to the `migrate` command to only run migrations meant to be run prior 
> to a deployment.
>
> I don't want to hijack the this thread to discuss it in details but feel 
> free to try it out and reach out personally if you'd like more details. 
> We've used it internally to deploy changes using ArgoCD to Kubernetes 
> clusters internally and I was planing on presenting the tool in the near 
> future at a Django event once we get more feedback about it.
>
> [0] https://github.com/charettes/django-syzygy
>
> Cheers,
> Simon
> Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit :
>
>> I'd personally like to see better support for safe / N-1 compatible 
>> migrations within Django itself, currently if you do CD / blue-green tower 
>> / etc. deployments you need to be very careful about the migration 
>> operations that you introduce version-to-version, although I'm not sure 
>> what that would look like.
>>
>> +1 to OIDC, CORS and DB defaults
>>
>> If nothing else, this thread has at least made me aware of some 
>> interesting tickets :-)
>>
>> Adrian
>>
>> On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:
>>
>>> I am not sure the db level defaults PR is suitable for a GSoC project at 
>>> this point - it’s pretty well developed. I think it could do with some 
>>> review and testing form those who are interested.
>>>
>>> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
>>> developers (Contributions to Django itself) <
>>> django-d...@googlegroups.com> wrote:
>>>
 +1 from me on DB defaults (constraints too). I've worked on many 
 systems where Django isn't the only place putting records into DBs and 
 having DB level defaults and constraints fixes a lot of common issues with 
 that. Currently I create an empty migrations to then add them in manually 
 when required


 +1 from me on moving models between apps, though I know it can be a 
 pain. Contacting and freelancing means you come across a lot of projects 
 where models are seeming in the wrong app or where you want to consolidate 
 apps and being able to move them cleaning would be a wonderful addition
 On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:

> I'd like to see database-level defaults supported in models and 
> migrations:
>
> https://code.djangoproject.com/ticket/470
>
> There's currently a PR open, which replaces an earlier 2020 PR
>
> https://github.com/django/django/pull/16092
>
> It would be a large benefit to those of us practicing continuous 
> deployment. It is also tricky enough that it would benefit from a 
> full-time 
> effort to implement and refactor.
>
> - John
>
> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
> wrote:
>
>> Hi all. 
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced.

Re: Standalon Django ORM

2022-12-12 Thread Jörg Breitbart

I tend to believe the opposite is true. Django was/is a successor in its 
field, because it offers an "out-of-the-box" or "batteries included" 
experience. Subsequently parts were shaped as needed for that bigger 
picture, e.g. the ORM became what it is today.


Does anyone still remember django versions with external south 
migrations? Was much more tricky to get done right, ppl would just 
forget it, do it in wrong order, whatsoever. Got basically fixed by the 
tighter integration with typical django project lifecycling.


By making the ORM an external lib with its own progression and 
versioning you'd reintroduce all that fuzz again, plus frictions from 
API changes, that seem logical from a db maintainer viewpoint, but make 
life harder at consumer end (would be django here). By keeping it in one 
place those tiny viewpoint differences can be leveled out upfront.


Ofc mammoths move slower, but they are also more resilient against 
disturbance. In terms of good long term maintainability the more 
granular/agile approach as seen in the JS-world still has to prove 
itself. Projects there need a lot more care of their dependency 
lists, and typically wont run anymore after 1-2 years without manually 
fixing this or that, because package xy of 100+ dependencies turned its 
API upside-down for no good reason.


So no, outsourcing things is not always a good idea.
All imho, ofc.

Cheers,
Jörg

--
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/aaf069ac-8db2-f538-6fe9-95d49bf49bc9%40netzkolchose.de.

Standalon Django ORM

2022-12-11 Thread Yonas

Hi,

Given the small number of Django ORM maintainers, making the ORM standalone 
will, among other things, increase the adoption of Django and bring in new 
maintainers.

An ORM inspired by Django ORM with over 3000+ stars: 
https://github.com/tortoise/tortoise-orm




-- 
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/2db8e46e-208f-45ce-9a0a-136686c99ef7n%40googlegroups.com.

Re: Make Cookies in Django follow the RFC correctly

2022-12-06 Thread Fernando Karchiloff

I've taken some time to read all the discussion again, imagine some 
scenarios, and read the comment that Collin made at it's own PR at GitHub 
here .

Most of them would need to break compatibility, and now I agree that there 
is not reason to do so. But I still think we can improve it somehow, and 
remain compatible.

Collin mentions using *MultiValueDict* instead of a simple *dict*. That way 
we can at least retrieve all cookies from the same name, and still maintain 
it's default behavior.

On Tuesday, December 6, 2022 at 6:08:50 AM UTC-3 Adam Johnson wrote:

> On the ticket associated with that PR ( 
> https://code.djangoproject.com/ticket/33212 ), there was a lot of 
> discussion, ending with Mariusz saying:
>
> As far as I'm aware both propositions (PR15015 and PR15019) are backward 
>> incompatible, so they are against out stability policy, unless it's not a 
>> security issue (which is not the case, IMO). We can make a breaking changes 
>> but we need a strong reason to do that. I'm concerned that changing the 
>> current behavior may actually make things worse in some cases. It seems to 
>> me that we need a broader discussion on this.
>>
>
> To continue the discussion I think we’ll need to hear about such a *strong 
> reason* to break compatibility, or a path forward that is not backwards 
> incompatible.
>
> Thanks,
>
> Adam
>
> On Mon, Dec 5, 2022 at 3:19 AM Fernando Karchiloff <
> fern...@ferkarchiloff.dev> wrote:
>
>> Currently the implementation of Cookies doesn't follow the RFC 6265 
>>  correctly, especially the *Path* 
>> part that seems to be ignored. That was already an attempt here: 
>> https://github.com/django/django/pull/15019, but @collinanderson 
>>  closed it for discussion first. Can 
>> we improve it 
>>
>> Reference:
>>
>>1. https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4
>>2. 
>>
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_where_cookies_are_sent
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/59cb0e52-69df-4e92-8046-2fd0be86fb9cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/2112d0e2-b245-410a-a9f9-a720fb0722c2n%40googlegroups.com.

Django bugfix release: 4.1.4

2022-12-06 Thread Carlton Gibson

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/dec/06/bugfix-release/

-- 
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/CAJwKpyQF7r1B4jwv%3D-idgJ2fEsgwHJvJU66qrJ-pCmQ_uHVrqg%40mail.gmail.com.

Re: Make Cookies in Django follow the RFC correctly

2022-12-06 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

On the ticket associated with that PR (
https://code.djangoproject.com/ticket/33212 ), there was a lot of
discussion, ending with Mariusz saying:

As far as I'm aware both propositions (PR15015 and PR15019) are backward
> incompatible, so they are against out stability policy, unless it's not a
> security issue (which is not the case, IMO). We can make a breaking changes
> but we need a strong reason to do that. I'm concerned that changing the
> current behavior may actually make things worse in some cases. It seems to
> me that we need a broader discussion on this.
>

To continue the discussion I think we’ll need to hear about such a *strong
reason* to break compatibility, or a path forward that is not backwards
incompatible.

Thanks,

Adam

On Mon, Dec 5, 2022 at 3:19 AM Fernando Karchiloff <
ferna...@ferkarchiloff.dev> wrote:

> Currently the implementation of Cookies doesn't follow the RFC 6265
>  correctly, especially the *Path*
> part that seems to be ignored. That was already an attempt here:
> https://github.com/django/django/pull/15019, but @collinanderson
>  closed it for discussion first. Can
> we improve it
>
> Reference:
>
>1. https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4
>2.
>
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_where_cookies_are_sent
>
> --
> 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/59cb0e52-69df-4e92-8046-2fd0be86fb9cn%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM0vVGKnujDOM%2Bk8qFOBkO_MtuOKL1dfRRZCFnhBZa07tQ%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

2022-12-05 Thread Andrew Godwin

I did some investigation of moving django-users and django-developers to 
the Forum right after DjangoCon; I wanted to see if we could import all the 
old posts too, which we probably could, but I'm not entirely sure of the 
utility of that.

I will say that the forum is a lot easier to moderate - the ability to 
moderate after a post has gone out, rather than gating all posts behind 
approval if they're untrusted, is a big step in itself, not to mention the 
ability to remove sensitive or offensive content once it's posted.

Andrew

On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:

> IMO django-announce and django-updates serve a very different purpose and 
> I would be against moving them if it were suggested.
>
> I am incredibly strongly in favour of moving django-developers and 
> django-users to the forums. IMO being able to more easily trap people 
> misusing this list as a tech support channel is itself reason enough to 
> move. Beyond that, I’d argue that the plentiful UX issues with Google 
> Groups, and mailing lists in general, certainly don’t do the community any 
> favours in terms of getting more people on board. 
>
> Kye
> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
> (Contributions to Django itself) , wrote:
>
> As someone who only just joined the forum -- I'm +1: 
>
>- The forum has seen great adoption from what I can tell (nearly half 
>the number of posts as django-developers during the same time period, not 
>bad given the mailing list's head start in subscribers).
>- It seems beneficial to house future conversations in a single place, 
>e.g., so members don't need to subscribe to both the mailing list and 
> forum 
>to get the full picture of current active development, set up two 
> different 
>sets of mail filters to tag things appropriately, etc... 
>
> Would the plan be to switch django-users as well? I think similar 
> arguments could be made for consolidating those...
>
> (On the other hand, I see little value in switching django-announce and 
> django-updates, but I'm not necessarily opposed to it either, especially if 
> there's a way to import the subscribers to those lists...)
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson  
> wrote:
>
>> Hey Roger,  
>>
>> Indeed it does. You can set up Email Mode (that may not be the actual 
>> name) and it’ll work just like a mailing list. 
>>
>> You can also subscribe to just a particular category, so the Internals 
>> one would map to the discussion on this list. 
>>
>>
>>
>> On Monday, 28 November 2022, Roger Gammans  
>> wrote:
>>
>>> Hi
>>>
>>> I can't speak for others, but I personally STRONGLY value the fact that 
>>> this discussion happens in my inbox, not on yet another website. 
>>>
>>> But perhaps the forum still supports this reading mode?
>>>
>>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>>
>>> Hi all.  
>>>
>>> Given the issues with Tom's access to the mailing list here, and the 
>>> fact that the Forum has been active for a few years now, and is a great 
>>> success, I'd like to revisit whether we can move on-mass (all few of us :) 
>>> over there? 
>>>
>>> We'd enjoy the benefits of a much nicer system. We'd not have issues 
>>> such as the current, and we'd be one less item in the pocket of a 
>>> mega-corp. (You can rank those as you will :) 
>>>
>>> Initially when this can up (a long time ago) Andrew and Tom discussed 
>>> whether we could import the history here into the forum. I think that's 
>>> unnecessary. We can still access the history here (until such a day as 
>>> Google takes it away) at worst -- but, rather, if we can get an archive we 
>>> could import it into read-only Datasette instance[0] — and that would 
>>> likely be good enough. 
>>>
>>> Can we move now? 
>>>
>>> Thanks. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> [0]: I'd happily do this. 
>>>
>>> --
>>> 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 view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> --
>>> 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 view this discussion on the web visit 
>>>

Make Cookies in Django follow the RFC correctly

2022-12-05 Thread Fernando Karchiloff

Currently the implementation of Cookies doesn't follow the RFC 6265 
 correctly, especially the *Path* 
part that seems to be ignored. That was already an attempt here: 
https://github.com/django/django/pull/15019, but @collinanderson 
 closed it for discussion first. Can we 
improve it 

Reference:

   1. https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4
   2. 
   
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_where_cookies_are_sent

-- 
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/59cb0e52-69df-4e92-8046-2fd0be86fb9cn%40googlegroups.com.

Re: Fellow Reports - November 2022

2022-12-05 Thread Mariusz Felisiak

Week ending December 4, 2022

*Triaged: *
https://code.djangoproject.com/ticket/34187 - UserCreationForm should
save data from ManyToMany form fields (accepted)
https://code.djangoproject.com/ticket/34189 - Code in Tutorial does not
work because of a ',' (invalid)
https://code.djangoproject.com/ticket/34190 - Add a dump and die
function to Django (wontfix)
https://code.djangoproject.com/ticket/34160 - Django 4.1 Expression
contains mixed types for (Big/Small)IntegerFields. (wontfix)
https://code.djangoproject.com/ticket/34191 - ModelAdmin.search_fields
fails for DecimalField and __exact (duplicate)
https://code.djangoproject.com/ticket/34193 - TestCase _fixture_teardown
breaks database MIRROR usage (duplicate)
https://code.djangoproject.com/ticket/34195 - Duplicate Records created
when specifying None as a target in a custom ManyToManyField (invalid)
https://code.djangoproject.com/ticket/34198 - Django content type
prefetching wrong data (duplicate)
https://code.djangoproject.com/ticket/34197 - method_decorator does not
work with async views (duplicate)
https://code.djangoproject.com/ticket/34199 - Add an example for
contrib.postgres.aggregates.StringAgg to docs. (accepted)

*Reviewed/committed: *
https://github.com/django/django/pull/16333 - Fixed #34187 -- Made
UserCreationForm save many-to-many fields.
https://github.com/django/django/pull/16250 - Fixed #33701 -- Added
fine-grained error locations to the technical 500 debug page.
https://github.com/django/django/pull/16340 - Refs #10929 -- Fixed
aggregates crash when passing strings as defaults.
https://github.com/django/django/pull/16318 - Refs #34095 -- Changed
more properties to use rem units in admin CSS.
https://github.com/django/django/pull/16345 - Refs #33308 -- Used
psycopg's errors instead of errorcodes.
https://github.com/django/django/pull/16346 - Refs #33308 -- Ensured
type handlers are registered for all PostgreSQL specific tests.
https://github.com/django/django/pull/16347 - Refs #33308 -- Added
get_type_oids() hook and simplified registering type handlers on
PostgreSQL.
https://github.com/django/django/pull/16245 - Refs #33308 -- Deprecated
support for passing encoded JSON string literals to JSONField & co.
https://github.com/django/django/pull/16351 - Refs #33308 -- Made
PostGISAdapter do not use psycopg2's Binary().
https://github.com/django/django/pull/16352 - Refs #33308 -- Avoided
passing None to RawSQL's params.

*Authored: *
https://github.com/django/django/pull/16335 - Refs #31169 -- Skipped
test_get_test_db_clone_settings_not_supported on not in-memory SQLite
database.
https://github.com/django/django/pull/16336 - Refs #34119 -- Skipped
test_callable_default_hidden_widget_value_not_overridden when JSONField is
not supported.
https://github.com/django/django/pull/16339 - Refs #33397, Refs #34160
-- Added release note for resolving output_field changes.

Best,
Mariusz

Re: Fellow Reports - November 2022

2022-12-05 Thread Mariusz Felisiak

Week ending November 27, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/34171 - QuerySet.bulk_create() 
crashes on mixed case columns in unique_fields/update_fields. (accepted) 
   https://code.djangoproject.com/ticket/34173 - SessionMiddleware only 
returns 400 or 500 error in case of DB issues. (invalid) 
   https://code.djangoproject.com/ticket/34175 - Cannot make whole test set 
to pass (invalid) 
   https://code.djangoproject.com/ticket/34177 - QuerySet.bulk_create() 
crashes on "pk" in unique_fields. (created) 
   https://code.djangoproject.com/ticket/34176 - Annotation's original 
field-name can clash with result field name over aggregation (accepted) 
   https://code.djangoproject.com/ticket/34178 - Prefetching a foreign key 
on GenericForeignKey results in incorrect queryset being selected 
(duplicate) 
   https://code.djangoproject.com/ticket/34179 - Django F expression not 
working as expected on MariaDB 10.5.13 (worksforme) 
   https://code.djangoproject.com/ticket/33403 - Annotate results change 
when filtering *after* the annotate (duplicate) 
   https://code.djangoproject.com/ticket/33050 - QuerySet.count() on 
combined queries with select_related() crashes on MySQL. (fixed) 
   https://code.djangoproject.com/ticket/29802 - Allow skipping CSRF check 
for Referer header (wontfix) 
   https://code.djangoproject.com/ticket/34182 - Is there a reason only the 
headers are checked when using the csrf token? (invalid) 
   https://code.djangoproject.com/ticket/34183 - Add a 
ChoicesMeta.max_length property returning the max_length when data type 
supports len() (wontfix) 

*Reviewed/committed: *
   https://github.com/django/django/pull/16208 - Fixed #31090 -- Logged 
transaction management queries. 
   https://github.com/django/django/pull/16161 - Used CSS flex for form 
rows. 
   https://github.com/django/django/pull/16315 - Fixed #34171 -- Fixed 
QuerySet.bulk_create() on fields with db_column in 
unique_fields/update_fields. 
   https://github.com/django/django/pull/16322 - Fixed #31679 -- Delayed 
annotating aggregations. 
   https://github.com/django/django/pull/16309 - Fixed #29062 -- Prevented 
possibility of database lock when using LiveServerTestCase with in-memory 
SQLite database. 
   https://github.com/django/django/pull/16326 - Fixed #34173 -- Skipped 
saving sessions on 5xx responses. 
   https://github.com/django/django/pull/16327 - Used 
DatabaseFeatures.django_test_skips to skip 
AssertNumQueriesUponConnectionTests tests. 
   https://github.com/django/django/pull/16312 - Fixed #33747 -- Added 
exception notes to the technical 500 debug page. 
   https://github.com/django/django/pull/16191 - Fixed #34103 -- Fixed 
logging SQL queries with duplicate parameters on Oracle. 

*Reviewed: *
   https://github.com/django/django/pull/15884 - Fixed #33868 -- Better 
labels for m2m fields. 

*Authored: *
   https://github.com/django/django/pull/16316 - Bumped 
gh-problem-matcher-wrap version to 2.0.0. 
   https://github.com/django/django/pull/16317 - Fixed #34177 -- Fixed 
QuerySet.bulk_create() crash on "pk" in unique_fields. 
   https://github.com/django/django/pull/16323 - Refs #33050 -- Added test 
for QuerySet.count() on combined queries with select_related(). 
   https://github.com/django/django/pull/16328 - Doc's check_password()'s 
setter and preferred arguments.

Best,
Mariusz

-- 
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/3819992d-36e5-41cf-aeea-bd9a657638a2n%40googlegroups.com.

Re: Technical Board vote on DEP 0012: The Steering Council

2022-12-03 Thread Andrew Godwin

Hi all,

I am pleased to announce that this vote has passed with 5 Board members voting 
+1 and no other votes.

I will now proceed to notify the DSF Board that they must hold a vote, as is 
required by DEP 10. Either they or I will update the list with information once 
that vote has been concluded and a result reached.

Andrew

On Wed, Nov 30, 2022, at 10:44 AM, Andrew Godwin wrote:
> Yes, I agree we can use the forum in future since it's less tied to Google.
> 
> Provided the current +5 vote carries through to the end of the voting period, 
> I will be suggesting that the Technical Board triggers the DEP 10 mechanism 
> where we move this to the membership for a vote once the DSF Board has 
> performed their vote, as it only seems appropriate.
> 
> Andrew
> 
> On Mon, Nov 28, 2022, at 9:30 PM, 'Adam Johnson' via Django developers  
> (Contributions to Django itself) wrote:
>> +1 from me
>> 
>> And +1 to using the forum in future
>> 
>> On Tue, 29 Nov 2022 at 00:23, charettes  wrote:
>>> +1 from me as well.
>>> 
>>> Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
 Hi All. 
 
 Tom Forbes is currently unable to post to the Google Group here, due to 
 Currently Undiagnosed Google Account Weirdness™. 
 
 For the record he's asked me to say that his vote is +1 in support of the 
 change, but I feel we should probably move voting to the forum because of 
 this. 
 
 
 Kind Regards,
 
 Carlton
 
 
 On Monday, 28 November 2022 at 09:52:35 UTC+1 f.apo...@gmail.com wrote:
> Hi,
> 
> +1 from me, but I'd like to ask the wider community (ie DSF members) 
> whether they support this change.
> 
> While there has been some opposition on whether a change likes this will 
> actually change things, I think that given the overall good reception of 
> the proposal it is at least worth to try it.
> 
> Cheers,
> Florian
> On Friday, November 25, 2022 at 10:04:36 AM UTC+1 Mariusz Felisiak wrote:
>> Thanks!
>> 
>> Reminder: according to DEP 10 voting will end on *December 2nd, 2022* 
>> *AoE* (members of the Technical Board may change their votes at any time 
>> prior to closing of the final voting period).
>>> 
>>> 
>>> -- 
>>> 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/378f606b-5d70-4013-a8d7-e8abb605f178n%40googlegroups.com
>>>  
>>> .
>> 
>> 
>> -- 
>> 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/CAMyDDM1dGUTiKTezaYDbqF0PYv1%3DEf%2Ba_VqT1J%2ByP%2BbgbdePZQ%40mail.gmail.com
>>  
>> .
> 
> 
> 
> -- 
> 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/12cfb130-17d0-4f42-9d58-631c927f473f%40app.fastmail.com
>  
> .

-- 
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/1d72d359-eff3-4b7d-90e7-2d971445b618%40app.fastmail.com.

Re: Async wrappers in contrib packages

2022-12-02 Thread Carlton Gibson

> But I can file a ticket just to track this one?

TBH I'd prefer it if you pondered the design here without opening a ticket
until such a point (if ever) that you have a concrete plan. (We'd likely
just close it as wontfix unless there's a specific idea on the table
anyway, so it's just noise at that point.)

I hope that makes sense.

Kind Regards,

Carlton

On Mon, 28 Nov 2022 at 16:53, Jon Janzen  wrote:

> Hey Carlton,
>
> There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view
>> decorators to be applied directly to async views."
>> I think this is likely the next step.
>>
>> There's a PR for that, which I think took a too complex approach (see
>> discussion). A simpler (more inline) take be good to see.
>>
>
> Thanks, I saw this ticket but it didn't look relevant when I was skimming
> the tracker. I'll take a closer look.
>
> > My personal interest in this is about django.contrib.auth (login,
>> authenticate, etc.)
>>
>> This was missing from the PR on #31949, so if you wanted to pick it up...
>> 
>>
>
> I'll take a closer look, I think I might be able to do that :D
>
>
>>
>> (Not sure about the value of rewriting the built-in views though if
>> that's what you're thinking of 樂)
>>
>> > ...and django.contrib.syndication (views.Feed)
>>
>> Not sure what you have in mind here. Perhaps explaining that in
>> more detail would help?
>> (I'm not immediately sure I see the benefit of async for the feed views?
>> 樂)
>>
>
> Not for the view itself, but for individual fields that compose the Feed.
>
> I want to define an async "item_categories" method when I subclass Feed
> due to an async-only permissions system I have that is out-of-scope here,
> but that isn't possible right now so I pre-compute each of these values and
> pass in a composite object with the source object and item_categories
> precomputed.
>
> I would rather just declare an async function and let the framework figure
> out how to resolve the values reasonably efficiently for me. I don't want
> to pay the cost of async_to_sync for each item in the feed :/
>
> I'm fine with setting this one aside, as I said I already have a
> workaround. But I can file a ticket just to track this one?
>
>  - Jon
>
> --
> 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/CAP1wFiCp_y%3DVygQxmat-JVR2cr_LjGTKDyQ7rXtg3ERrzdfXXw%40mail.gmail.com
> 
> .
>

-- 
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/CAJwKpyRp5OLrEB%3DRD4zONCsChZMcBSEpqyiSCmoR9XB83Y6w5w%40mail.gmail.com.

Re: Technical Board vote on DEP 0012: The Steering Council

2022-11-30 Thread Andrew Godwin

Yes, I agree we can use the forum in future since it's less tied to Google.

Provided the current +5 vote carries through to the end of the voting period, I 
will be suggesting that the Technical Board triggers the DEP 10 mechanism where 
we move this to the membership for a vote once the DSF Board has performed 
their vote, as it only seems appropriate.

Andrew

On Mon, Nov 28, 2022, at 9:30 PM, 'Adam Johnson' via Django developers  
(Contributions to Django itself) wrote:
> +1 from me
> 
> And +1 to using the forum in future
> 
> On Tue, 29 Nov 2022 at 00:23, charettes  wrote:
>> +1 from me as well.
>> 
>> Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
>>> Hi All. 
>>> 
>>> Tom Forbes is currently unable to post to the Google Group here, due to 
>>> Currently Undiagnosed Google Account Weirdness™. 
>>> 
>>> For the record he's asked me to say that his vote is +1 in support of the 
>>> change, but I feel we should probably move voting to the forum because of 
>>> this. 
>>> 
>>> 
>>> Kind Regards,
>>> 
>>> Carlton
>>> 
>>> 
>>> On Monday, 28 November 2022 at 09:52:35 UTC+1 f.apo...@gmail.com wrote:
 Hi,
 
 +1 from me, but I'd like to ask the wider community (ie DSF members) 
 whether they support this change.
 
 While there has been some opposition on whether a change likes this will 
 actually change things, I think that given the overall good reception of 
 the proposal it is at least worth to try it.
 
 Cheers,
 Florian
 On Friday, November 25, 2022 at 10:04:36 AM UTC+1 Mariusz Felisiak wrote:
> Thanks!
> 
> Reminder: according to DEP 10 voting will end on *December 2nd, 2022* 
> *AoE* (members of the Technical Board may change their votes at any time 
> prior to closing of the final voting period).
>> 
>> 
>> -- 
>> 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/378f606b-5d70-4013-a8d7-e8abb605f178n%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> 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/CAMyDDM1dGUTiKTezaYDbqF0PYv1%3DEf%2Ba_VqT1J%2ByP%2BbgbdePZQ%40mail.gmail.com
>  
> .

-- 
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/12cfb130-17d0-4f42-9d58-631c927f473f%40app.fastmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-29 Thread charettes

Adrian,

> I'd personally like to see better support for safe / N-1 compatible 
migrations within Django itself, currently if you do CD / blue-green tower 
/ etc. deployments you need to be very careful about the migration 
operations that you introduce version-to-version, although I'm not sure 
what that would look like.

There's a little project that we use at $WORK to do just that[0]. I'm not 
sure its inclusion in core is even proposable at this time as is still has 
received very little feedback from external users but the gist of the tool 
is that it introduces a notion of phases to migrations (pre and 
post-deployment) and augments the `makemigrations` command so it splits 
operations that require multiple phases in multiple migrations and adds a 
`--pre-deploy` 
flag to the `migrate` command to only run migrations meant to be run prior 
to a deployment.

I don't want to hijack the this thread to discuss it in details but feel 
free to try it out and reach out personally if you'd like more details. 
We've used it internally to deploy changes using ArgoCD to Kubernetes 
clusters internally and I was planing on presenting the tool in the near 
future at a Django event once we get more feedback about it.

[0] https://github.com/charettes/django-syzygy

Cheers,
Simon
Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit :

> I'd personally like to see better support for safe / N-1 compatible 
> migrations within Django itself, currently if you do CD / blue-green tower 
> / etc. deployments you need to be very careful about the migration 
> operations that you introduce version-to-version, although I'm not sure 
> what that would look like.
>
> +1 to OIDC, CORS and DB defaults
>
> If nothing else, this thread has at least made me aware of some 
> interesting tickets :-)
>
> Adrian
>
> On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:
>
>> I am not sure the db level defaults PR is suitable for a GSoC project at 
>> this point - it’s pretty well developed. I think it could do with some 
>> review and testing form those who are interested.
>>
>> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
>> developers (Contributions to Django itself)  
>> wrote:
>>
>>> +1 from me on DB defaults (constraints too). I've worked on many systems 
>>> where Django isn't the only place putting records into DBs and having DB 
>>> level defaults and constraints fixes a lot of common issues with that. 
>>> Currently I create an empty migrations to then add them in manually when 
>>> required
>>>
>>>
>>> +1 from me on moving models between apps, though I know it can be a 
>>> pain. Contacting and freelancing means you come across a lot of projects 
>>> where models are seeming in the wrong app or where you want to consolidate 
>>> apps and being able to move them cleaning would be a wonderful addition
>>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>>>
 I'd like to see database-level defaults supported in models and 
 migrations:

 https://code.djangoproject.com/ticket/470

 There's currently a PR open, which replaces an earlier 2020 PR

 https://github.com/django/django/pull/16092

 It would be a large benefit to those of us practicing continuous 
 deployment. It is also tricky enough that it would benefit from a 
 full-time 
 effort to implement and refactor.

 - John

 On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
 wrote:

> Hi all. 
>
> Google Summer of Code (GSoC) for 2023 has just been announced. 
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent 
> successes include: 
>
> * The django-stubs mypy plugin. 
> * The cross-db JSON field. 
> * The Redis cache backend. 
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project. 
> * ... 
>
> Application deadline for Orgs is February 7. I'll begin working on it 
> after the New Year. 
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
> Good Ideas List
> section. 
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors 
> to complete. 
>
> i.e. "short" or "long" projects. 
>
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*. 
>
> I put "Technical Board?" in the subject because we're short a list of 
> project
> ideas for the technical direction of Django going forward, and maybe 
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is 
> because that's not 
> meant to exclude other input.
>
> Here's last year's list for reference: 
>

Re: Set a reasonable default for EMAIL_TIMEOUT

2022-11-29 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Federico - I think we’d like to see a few more “pro”s in the thread.

Personally, I am pro adding a default timeout. The lack of a default
timeout in *requests* is a constant source of outages, which lead me to
write this hack

to patch it. httpx has learned from this by setting a default timeout.

It would be good to see some research whether a default in smtplib was ever
explicitly discussed.

On Tue, Nov 29, 2022 at 5:54 PM Federico Capoano 
wrote:

> Hi everyone,
>
> do you think you are against on opening an issue for this?
> I had already opened an issue
>  which was marked as
> wontfix and I was asked to open this discussion here.
>
> Best regards
> Federico
>
> On Monday, November 21, 2022 at 5:31:27 PM UTC-3 Federico Capoano wrote:
>
>> Hi there,
>>
>> yes I can add EMAIL_TIMEOUT in my applications and I am already doing
>> that.
>>
>> The reason I wanted to bring this up here is that I care about Django.
>> This behavior goes against a well known concept of the Unix Philosophy
>> which is to  "Write programs which fail in a way that is easy to diagnose".
>>
>> I believe we can all agree that any potentially long running operation
>> should have a default timeout after which the operation fails and a trace
>> is left on a log somewhere for the system administrators to find
>> I can't see the benefit in not failing, not leaving log traces and
>> keeping an app blocked indefinitely.
>>
>> What are the benefits vs the downsides of such a change?
>>
>> Benefit: any issue in production systems will be quickly understood and
>> dealt with.
>> Downsides? Backward compatibility? Systems relying on the default timeout
>> being set elsewhere? Anything else?
>>
>> Even if we allow configuring different email backends, I am still
>> wonderfing: why do we think it's good to have an email sending operation
>> which can potentially stall indefinitely?
>>
>> Best regards
>> Federico
>> On Friday, November 18, 2022 at 11:28:14 AM UTC-3 Michiel Beijen wrote:
>>
>>> Hi Mariusz,
>>>
>>> > Op 17 nov. 2022, om 18:18 heeft Mariusz Felisiak <
>>> felisiak...@gmail.com> het volgende geschreven:
>>> >
>>> > "Why is there no default for EMAIL_TIMEOUT?"
>>> > The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL
>>> and we only pass the "timeout" parameter to the smtplib API, so I'd first
>>> ask why there is no default value for a timeout parameter in smtplib.
>>>
>>> Well, Django’s docs say:
>>>
>>> > If unspecified, the default timeout will be the one provided by
>>> socket.getdefaulttimeout(), which defaults to None(no timeout).
>>> (ref https://docs.djangoproject.com/en/4.1/topics/email/#smtp-backend)
>>>
>>> So if you say: why is there no default value in smtplib, the smtplib
>>> maintainer can so go one level up and ask why there is no default timeout
>>> for `socket` :D
>>>
>>> Nevertheless, I would argue that having a timeout in django, set to a
>>> rather conservative value such as 60 seconds, is much better than having no
>>> timeout at all; especially because what the OP posted:
>>>
>>> > so at least if and when this happens, developers will find error
>>> traces in the logs and quickly understand where the problem is coming from,
>>> instead of spending hours to debug it like I did in the past week.
>>>
>>> In the typical scenario, people are much better off with specified
>>> timeouts than with a timeout of None
>>>
>>> —
>>> Michiel
>>>
>>> --
> 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/c62d1e69-5b9a-487f-8ca8-a843a7bbc914n%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM06GnVo_Pt4ow-rrRSfVA8x%3DZ%2BB0_9L19G3RJsoHODzjg%40mail.gmail.com.

Re: Set a reasonable default for EMAIL_TIMEOUT

2022-11-29 Thread Federico Capoano

Hi everyone,

do you think you are against on opening an issue for this?
I had already opened an issue 
 which was marked as 
wontfix and I was asked to open this discussion here.

Best regards
Federico

On Monday, November 21, 2022 at 5:31:27 PM UTC-3 Federico Capoano wrote:

> Hi there,
>
> yes I can add EMAIL_TIMEOUT in my applications and I am already doing that.
>
> The reason I wanted to bring this up here is that I care about Django.
> This behavior goes against a well known concept of the Unix Philosophy 
> which is to  "Write programs which fail in a way that is easy to diagnose".
>
> I believe we can all agree that any potentially long running operation 
> should have a default timeout after which the operation fails and a trace 
> is left on a log somewhere for the system administrators to find
> I can't see the benefit in not failing, not leaving log traces and keeping 
> an app blocked indefinitely.
>
> What are the benefits vs the downsides of such a change?
>
> Benefit: any issue in production systems will be quickly understood and 
> dealt with.
> Downsides? Backward compatibility? Systems relying on the default timeout 
> being set elsewhere? Anything else?
>
> Even if we allow configuring different email backends, I am still 
> wonderfing: why do we think it's good to have an email sending operation 
> which can potentially stall indefinitely?
>
> Best regards
> Federico
> On Friday, November 18, 2022 at 11:28:14 AM UTC-3 Michiel Beijen wrote:
>
>> Hi Mariusz, 
>>
>> > Op 17 nov. 2022, om 18:18 heeft Mariusz Felisiak  
>> het volgende geschreven: 
>> > 
>> > "Why is there no default for EMAIL_TIMEOUT?" 
>> > The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL and 
>> we only pass the "timeout" parameter to the smtplib API, so I'd first ask 
>> why there is no default value for a timeout parameter in smtplib. 
>>
>> Well, Django’s docs say: 
>>
>> > If unspecified, the default timeout will be the one provided by 
>> socket.getdefaulttimeout(), which defaults to None(no timeout). 
>> (ref https://docs.djangoproject.com/en/4.1/topics/email/#smtp-backend) 
>>
>> So if you say: why is there no default value in smtplib, the smtplib 
>> maintainer can so go one level up and ask why there is no default timeout 
>> for `socket` :D 
>>
>> Nevertheless, I would argue that having a timeout in django, set to a 
>> rather conservative value such as 60 seconds, is much better than having no 
>> timeout at all; especially because what the OP posted: 
>>
>> > so at least if and when this happens, developers will find error traces 
>> in the logs and quickly understand where the problem is coming from, 
>> instead of spending hours to debug it like I did in the past week. 
>>
>> In the typical scenario, people are much better off with specified 
>> timeouts than with a timeout of None 
>>
>> — 
>> Michiel 
>>
>>

-- 
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/c62d1e69-5b9a-487f-8ca8-a843a7bbc914n%40googlegroups.com.

Re: #21978 include production-ready web server

2022-11-29 Thread 'Tobias McNulty' via Django developers (Contributions to Django itself)

At Florian's suggestion in another thread, I propose that we move further 
discussion of the settings refactor to the forum:  
https://forum.djangoproject.com/t/settings-refactor/17352

On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote:

> The speckenv example highlights the problems when using `literal_eval`: 
> A=[] will parse as list but A=[a] will parse as string again (if I read the 
> code correctly). This ambiguity makes it really hard to explain. When using 
> `literal_eval` one imo has to be consistent and don't fall back to a str 
> and require strings to be written as A='[]' (with quotes). Then again this 
> is rather ugly and hard to get right/explain if you try to pass that in via 
> a shell ala `A='[]' django-admin runserver` and now A is a list again :/
>
> Cheers,
> Florian
>
> On Wednesday, November 2, 2022 at 8:20:00 AM UTC+1 m...@feinheit.ch wrote:
>
>> On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner  
>> wrote:
>>
>>> Right, that would work. I am wondering though if we want to go all in on 
>>> a typed config object like that or in a first step only have a simple API 
>>> like `config.get('DEBUG', cast=bool)`.
>>>
>>>
>> I found a neat trick in a 12factor library somewhere (I don't remember 
>> where unfortunately) of using ast.literal_eval for config variables:
>> https://docs.python.org/3/library/ast.html#ast.literal_eval
>>
>> https://github.com/matthiask/speckenv/blob/94722bcc95b94a9e6b1a1aada2bd977c43bfb767/speckenv.py#L63
>>
>> This may be too cute or magical for Django. It certainly works well and 
>> avoids having to be overspecific with types. I find it boring to tell the 
>> config loader that True is a bool and "hello" is a string. That being said 
>> I don't really have a strong preference here apart from having a strong 
>> dislike for the "several settings files" pattern. It's much more obvious to 
>> me if e.g. `MIDDLEWARE` is configured in a single location and not modified 
>> in other files. 
>>
>> Thanks,
>> Matthias
>>
>>
>>
>>

-- 
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/3c783c4b-13ec-4e23-9fe1-101b92e4c49bn%40googlegroups.com.

Re: Integrate dj-database-url into Django

2022-11-29 Thread 'Tobias McNulty' via Django developers (Contributions to Django itself)

I started a forum thread on the settings refactor here:
https://forum.djangoproject.com/t/settings-refactor/17352

Regarding the original topic of this thread (
https://code.djangoproject.com/ticket/28236), are we ready to close this as
wontfix? I'm okay not proceeding with it (dj-database-url, django-environ,
etc. are more than fine as stop-gaps), but it would be nice to preclude
further effort/work on this issue if we're never going to move forward with
it. While I realize it was never Accepted, that nuance may be lost on new
visitors given the prior work history on the issue...

Cheers,
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/CAMGFDKSHu9mx366iMkrnZseCtTaPXSbvV3dbNTLosL0B2m-L4Q%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-29 Thread Adrian Torres

I'd personally like to see better support for safe / N-1 compatible 
migrations within Django itself, currently if you do CD / blue-green tower 
/ etc. deployments you need to be very careful about the migration 
operations that you introduce version-to-version, although I'm not sure 
what that would look like.

+1 to OIDC, CORS and DB defaults

If nothing else, this thread has at least made me aware of some interesting 
tickets :-)

Adrian

On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:

> I am not sure the db level defaults PR is suitable for a GSoC project at 
> this point - it’s pretty well developed. I think it could do with some 
> review and testing form those who are interested.
>
> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
> developers (Contributions to Django itself)  
> wrote:
>
>> +1 from me on DB defaults (constraints too). I've worked on many systems 
>> where Django isn't the only place putting records into DBs and having DB 
>> level defaults and constraints fixes a lot of common issues with that. 
>> Currently I create an empty migrations to then add them in manually when 
>> required
>>
>>
>> +1 from me on moving models between apps, though I know it can be a pain. 
>> Contacting and freelancing means you come across a lot of projects where 
>> models are seeming in the wrong app or where you want to consolidate apps 
>> and being able to move them cleaning would be a wonderful addition
>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>>
>>> I'd like to see database-level defaults supported in models and 
>>> migrations:
>>>
>>> https://code.djangoproject.com/ticket/470
>>>
>>> There's currently a PR open, which replaces an earlier 2020 PR
>>>
>>> https://github.com/django/django/pull/16092
>>>
>>> It would be a large benefit to those of us practicing continuous 
>>> deployment. It is also tricky enough that it would benefit from a full-time 
>>> effort to implement and refactor.
>>>
>>> - John
>>>
>>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
>>> wrote:
>>>
 Hi all. 

 Google Summer of Code (GSoC) for 2023 has just been announced. 

 https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

 Django has participated many times, and it's been a real boon. Recent 
 successes include: 

 * The django-stubs mypy plugin. 
 * The cross-db JSON field. 
 * The Redis cache backend. 
 * Per model-class (field instance) custom lookups
 * Setup of the django-asv benchmarking project. 
 * ... 

 Application deadline for Orgs is February 7. I'll begin working on it 
 after the New Year. 

 Main bit is an ideas list for projects. The GSoC guide has a Writing a 
 Good Ideas List
 section. 

 > Projects should take ~175 hours or ~350 hours for GSoC contributors 
 to complete. 

 i.e. "short" or "long" projects. 
 https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

 I'm writing here *to solicit input on project ideas*. 

 I put "Technical Board?" in the subject because we're short a list of 
 project
 ideas for the technical direction of Django going forward, and maybe 
 thinking
 in terms of GSoC could be a way of bootstrapping that. The "?" is 
 because that's not 
 meant to exclude other input.

 Here's last year's list for reference: 
 https://code.djangoproject.com/wiki/SummerOfCode2022

 - Some of those were done: benchmarking (but that could be built on) 
 and per-instance 
   field lookups.

 - Rate-limiting is a no-go I think: we couldn't come to any decent 
 agreement on scope, 
   so it's better to live as a third-party package. 

 - I've tried to include folks from the wider ecosystem in previous 
 years. Two years ago 
   we had both Wagtail and django-stubs projects. Wagtail then (last 
 year)
   applied in their own right, to great success. I'd like to offer that 
 help
   again to e.g. Jazzband or other established projects, assuming 
 maintainers
   feel they have the capacity to mentor. (It's a minor increment to my 
 effort
   for a good return I think.)

 No urgency but, can I ask you to put your grey cells into action? 

 Thanks. 

 Kind Regards,

 Carlton

 -- 

>>> 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 view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com

Re: Potential way forward for DATABASE_URL

2022-11-29 Thread Raphael G

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 really needs to 
>> be "right". Personally I believe that Django's very good deprecation 
>> strategy means that big mess-ups are fortunately fixable, but it's work for 
>> everyone (and likely would involve either some weird hack in the 
>> intermediate steps). 
>>
>> I would like to offer an alternative narrative to the background here, 
>> that I think more strongly justifies introducing this into Django proper. 
>> It is not the real narrative, but it is a narrative. 
>>
>> URL-based configuration conventions exist for database backends and cache 
>> backends in various libraries. This lets us pass in credentials as one 
>> string rather than a bunch of components to be assembled. But each backend 
>> will handle things like configuration options within those URLs 
>> differently. Overall URL parsing logic is all very similar, with important 
>> differences coming from how the database name might get passed in, how 
>> certain connection options get passed in, etc.
>>
>> So it would be helpful to provide both a method on DatabaseWrapper that 
>> does basic URL parsing (to pull out the host/username/password), and for 
>> Django's supported DB backends to override this URL parsing method based on 
>> whatever convention is being applied by other libraries (or from 
>> backend-specific tooling). Same thing for caches. 
>>
>> Because this is ultimately a bit backend-specific, having this logic 
>> close to the actual backend connection logic (so on these classes 
>> themselves) is the most natural, more so than having separate dictionaries 
>> with mappings to backends. New configuration option? Would be good to make 
>> sure it's handled in the URL parser as well, somehow.
>>
>> Rambling a bit, but really am open to any(?) way forward that leads to "I 
>> will not need to install an extra package to handle this, nor am I 
>> personally parsing the URL with urllib.parse", and am ready to do the 
>> legwork. 
>>
>> Speaking to that, if we have consensus on the principle, what would be 
>> the right step forward? An actual DEP?
>>
>> Raphael
>>
>> On Tuesday,

Re: Potential way forward for DATABASE_URL

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 really needs to be
> "right". Personally I believe that Django's very good deprecation strategy
> means that big mess-ups are fortunately fixable, but it's work for everyone
> (and likely would involve either some weird hack in the intermediate
> steps).
>
> I would like to offer an alternative narrative to the background here,
> that I think more strongly justifies introducing this into Django proper.
> It is not the real narrative, but it is a narrative.
>
> URL-based configuration conventions exist for database backends and cache
> backends in various libraries. This lets us pass in credentials as one
> string rather than a bunch of components to be assembled. But each backend
> will handle things like configuration options within those URLs
> differently. Overall URL parsing logic is all very similar, with important
> differences coming from how the database name might get passed in, how
> certain connection options get passed in, etc.
>
> So it would be helpful to provide both a method on DatabaseWrapper that
> does basic URL parsing (to pull out the host/username/password), and for
> Django's supported DB backends to override this URL parsing method based on
> whatever convention is being applied by other libraries (or from
> backend-specific tooling). Same thing for caches.
>
> Because this is ultimately a bit backend-specific, having this logic close
> to the actual backend connection logic (so on these classes themselves) is
> the most natural, more so than having separate dictionaries with mappings
> to backends. New configuration option? Would be good to make sure it's
> handled in the URL parser as well, somehow.
>
> Rambling a bit, but really am open to any(?) way forward that leads to "I
> will not need to install an extra package to handle this, nor am I
> personally parsing the URL with urllib.parse", and am ready to do the
> legwork.
>
> Speaking to that, if we have consensus on the principle, what would be the
> right step forward? An actual DEP?
>
> Raphael
>
> On Tuesday, November 29, 2022 at 1:47:24 PM UTC+9 Adam Johnson wrote:
>
>> 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 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 said it still supplies
>>> an easily searchable answer for "Django DATABASE_URL."
>>>
>>> Cheers,
>>> Tobias
>>>
>>>
>>> On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:
>>>
 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

Re: Integrate dj-database-url into Django

2022-11-28 Thread Florian Apolloner

The thread that Carlton refers to is 
https://groups.google.com/g/django-developers/c/q20_Cxske88 -- don't be 
deterred by the title of it, it really talks about handling settings as 
well :)

I kinda agree with James. I'd like to have a proper answer for handling 
settings rather then go setting by setting. The main difficulty I see is to 
decide whether we really go low-level in the sense of providing a simple 
API that can get settings from a variety of sources (the `get("key", 
default)`) or if we go further and provide a newer opinionated high level 
API like pydantic etc… Both approaches have their ups and downs. But before 
repeating everything from the other thread here, I'd like to ask that we 
decide on one spot to continue this discussion and then stick to that one 
(the settings one, as noted by James I am also rather -0 on adding 
DATABASE_URL support now). Titlewise neither of the two threads seem to fit 
very well so we can just as well open a topic on the forum ;)

Cheers,
Florian
On Tuesday, November 29, 2022 at 8:09:17 AM UTC+1 carlton...@gmail.com 
wrote:

> This must be do-able now. 
>
> There was some discussion of something along these lines a couple of years 
> ago, with the idea of doing it for GSoC. 
> There was much back-and-forth but no consensus. 
>
> It has then come up again with Peter's suggestions about making it easier 
> to get to a deployment ready state. 
> The discussion with Florian there touches on this exact point.
>
> It looks like there's two sides to it: 
> * A user-facing API, perhaps like ...get("key" default) 樂
> * A pluggable backend API for that, so folks can use things like Vault and 
> temporary secrets files as well as the environment. 
>
> If I followed correctly, it would be OK to ship an environment backend 
> with Django (perhaps with some simpler ones for development/testing) 
> leaving more advanced options open. 
> I think Florian has ideas here. 
>
>
> On Mon, 28 Nov 2022 at 23:20, James Bennett  wrote:
>
>> It feels like this needs to be a broader conversation about not just
>> changing DATABASES to accept a URL, or integrating a particular
>> database-settings project, but to re-think how Django does
>> settings-from-environment as a whole.
>>
>> When I'm setting up new Django-based projects, django-environ
>> (https://pypi.org/project/django-environ/) is now one of the first
>> packages I reach for, and it has a much more comprehensive set of
>> helpers for configuring Django from environment variables and doing
>> appropriate parsing and type casts.
>>
>> There also is Pydantic's settings model
>> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
>> annotations to drive parsing/validation/type-casting and defaults to
>> reading from environment variables.
>>
>> I'd rather see some sort of comprehensive "make settings-from-env
>> easier" in Django than one-off pieces like a database URL.
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com
>> .
>>
>

-- 
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/dd5a98e9-a7f7-4db8-a61d-697210bd6970n%40googlegroups.com.

Re: Integrate dj-database-url into Django

2022-11-28 Thread 'Kye Russell' via Django developers (Contributions to Django itself)

This must be do-able now.

There was some discussion of something along these lines a couple of years
ago, with the idea of doing it for GSoC.
There was much back-and-forth but no consensus.

It has then come up again with Peter's suggestions about making it easier
to get to a deployment ready state.
The discussion with Florian there touches on this exact point.

It looks like there's two sides to it:
* A user-facing API, perhaps like ...get("key" default) 樂
* A pluggable backend API for that, so folks can use things like Vault and
temporary secrets files as well as the environment.

If I followed correctly, it would be OK to ship an environment backend with
Django (perhaps with some simpler ones for development/testing) leaving
more advanced options open.
I think Florian has ideas here.

On Mon, 28 Nov 2022 at 23:20, James Bennett  wrote:

> It feels like this needs to be a broader conversation about not just
> changing DATABASES to accept a URL, or integrating a particular
> database-settings project, but to re-think how Django does
> settings-from-environment as a whole.
>
> When I'm setting up new Django-based projects, django-environ
> (https://pypi.org/project/django-environ/) is now one of the first
> packages I reach for, and it has a much more comprehensive set of
> helpers for configuring Django from environment variables and doing
> appropriate parsing and type casts.
>
> There also is Pydantic's settings model
> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
> annotations to drive parsing/validation/type-casting and defaults to
> reading from environment variables.
>
> I'd rather see some sort of comprehensive "make settings-from-env
> easier" in Django than one-off pieces like a database URL.
>
> --
> 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/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com
> .
>

-- 
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/CAJwKpyRXH5BgJDXVrDXJqfLYWjdDJ3Mf0rZyRPDgo3VrRdbf0Q%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

2022-11-28 Thread Raphael G

(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 really needs to be 
"right". Personally I believe that Django's very good deprecation strategy 
means that big mess-ups are fortunately fixable, but it's work for everyone 
(and likely would involve either some weird hack in the intermediate 
steps). 

I would like to offer an alternative narrative to the background here, that 
I think more strongly justifies introducing this into Django proper. It is 
not the real narrative, but it is a narrative. 

URL-based configuration conventions exist for database backends and cache 
backends in various libraries. This lets us pass in credentials as one 
string rather than a bunch of components to be assembled. But each backend 
will handle things like configuration options within those URLs 
differently. Overall URL parsing logic is all very similar, with important 
differences coming from how the database name might get passed in, how 
certain connection options get passed in, etc.

So it would be helpful to provide both a method on DatabaseWrapper that 
does basic URL parsing (to pull out the host/username/password), and for 
Django's supported DB backends to override this URL parsing method based on 
whatever convention is being applied by other libraries (or from 
backend-specific tooling). Same thing for caches. 

Because this is ultimately a bit backend-specific, having this logic close 
to the actual backend connection logic (so on these classes themselves) is 
the most natural, more so than having separate dictionaries with mappings 
to backends. New configuration option? Would be good to make sure it's 
handled in the URL parser as well, somehow.

Rambling a bit, but really am open to any(?) way forward that leads to "I 
will not need to install an extra package to handle this, nor am I 
personally parsing the URL with urllib.parse", and am ready to do the 
legwork. 

Speaking to that, if we have consensus on the principle, what would be the 
right step forward? An actual DEP?

Raphael

On Tuesday, November 29, 2022 at 1:47:24 PM UTC+9 Adam Johnson wrote:

> 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 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 said it still supplies an 
>> easily searchable answer for "Django DATABASE_URL."
>>
>> Cheers,
>> Tobias
>>
>>
>> On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:
>>
>>> 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 
>>>
>>>

Re: Can we move the activity on this list to the Forum now?

IMO django-announce and django-updates serve a very different purpose and I 
would be against moving them if it were suggested.

I am incredibly strongly in favour of moving django-developers and django-users 
to the forums. IMO being able to more easily trap people misusing this list as 
a tech support channel is itself reason enough to move. Beyond that, I’d argue 
that the plentiful UX issues with Google Groups, and mailing lists in general, 
certainly don’t do the community any favours in terms of getting more people on 
board.

Kye
On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers 
(Contributions to Django itself) , wrote:
> As someone who only just joined the forum -- I'm +1:
>
> • The forum has seen great adoption from what I can tell (nearly half the 
> number of posts as django-developers during the same time period, not bad 
> given the mailing list's head start in subscribers).
> • It seems beneficial to house future conversations in a single place, e.g., 
> so members don't need to subscribe to both the mailing list and forum to get 
> the full picture of current active development, set up two different sets of 
> mail filters to tag things appropriately, etc...
>
> Would the plan be to switch django-users as well? I think similar arguments 
> could be made for consolidating those...
>
> (On the other hand, I see little value in switching django-announce and 
> django-updates, but I'm not necessarily opposed to it either, especially if 
> there's a way to import the subscribers to those lists...)
>
> Cheers,
>
> Tobias McNulty
> Chief Executive Officer
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> > On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson  
> > wrote:
> > > Hey Roger,
> > >
> > > Indeed it does. You can set up Email Mode (that may not be the actual 
> > > name) and it’ll work just like a mailing list.
> > >
> > > You can also subscribe to just a particular category, so the Internals 
> > > one would map to the discussion on this list.
> > >
> > >
> > >
> > > On Monday, 28 November 2022, Roger Gammans  
> > > wrote:
> > > > Hi
> > > >
> > > > I can't speak for others, but I personally STRONGLY value the fact that 
> > > > this discussion happens in my inbox, not on yet another website.
> > > >
> > > > But perhaps the forum still supports this reading mode?
> > > >
> > > > On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
> > > > > Hi all.
> > > > >
> > > > > Given the issues with Tom's access to the mailing list here, and the 
> > > > > fact that the Forum has been active for a few years now, and is a 
> > > > > great success, I'd like to revisit whether we can move on-mass (all 
> > > > > few of us :) over there?
> > > > >
> > > > > We'd enjoy the benefits of a much nicer system. We'd not have issues 
> > > > > such as the current, and we'd be one less item in the pocket of a 
> > > > > mega-corp. (You can rank those as you will :)
> > > > >
> > > > > Initially when this can up (a long time ago) Andrew and Tom discussed 
> > > > > whether we could import the history here into the forum. I think 
> > > > > that's unnecessary. We can still access the history here (until such 
> > > > > a day as Google takes it away) at worst -- but, rather, if we can get 
> > > > > an archive we could import it into read-only Datasette instance[0] — 
> > > > > and that would likely be good enough.
> > > > >
> > > > > Can we move now?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Kind Regards,
> > > > >
> > > > > Carlton
> > > > >
> > > > >
> > > > > [0]: I'd happily do this.
> > > > > --
> > > > > 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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com.
> > > > --
> > > > 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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk.
> > > --
> > > 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 
> > >

Re: Can we move the activity on this list to the Forum now?

2022-11-28 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

Big +1 from me, I love the forum. It’s a lot more discoverable and powerful.

On Mon, 28 Nov 2022 at 15:22, 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> As someone who only just joined the forum -- I'm +1:
>
>- The forum has seen great adoption from what I can tell (nearly half
>the number of posts as django-developers during the same time period, not
>bad given the mailing list's head start in subscribers).
>- It seems beneficial to house future conversations in a single place,
>e.g., so members don't need to subscribe to both the mailing list and forum
>to get the full picture of current active development, set up two different
>sets of mail filters to tag things appropriately, etc...
>
> Would the plan be to switch django-users as well? I think similar
> arguments could be made for consolidating those...
>
> (On the other hand, I see little value in switching django-announce and
> django-updates, but I'm not necessarily opposed to it either, especially if
> there's a way to import the subscribers to those lists...)
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
> wrote:
>
>> Hey Roger,
>>
>> Indeed it does. You can set up Email Mode (that may not be the actual
>> name) and it’ll work just like a mailing list.
>>
>> You can also subscribe to just a particular category, so the Internals
>> one would map to the discussion on this list.
>>
>>
>>
>> On Monday, 28 November 2022, Roger Gammans 
>> wrote:
>>
>>> Hi
>>>
>>> I can't speak for others, but I personally STRONGLY value the fact that
>>> this discussion happens in my inbox, not on yet another website.
>>>
>>> But perhaps the forum still supports this reading mode?
>>>
>>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>>
>>> Hi all.
>>>
>>> Given the issues with Tom's access to the mailing list here, and the
>>> fact that the Forum has been active for a few years now, and is a great
>>> success, I'd like to revisit whether we can move on-mass (all few of us :)
>>> over there?
>>>
>>> We'd enjoy the benefits of a much nicer system. We'd not have issues
>>> such as the current, and we'd be one less item in the pocket of a
>>> mega-corp. (You can rank those as you will :)
>>>
>>> Initially when this can up (a long time ago) Andrew and Tom discussed
>>> whether we could import the history here into the forum. I think that's
>>> unnecessary. We can still access the history here (until such a day as
>>> Google takes it away) at worst -- but, rather, if we can get an archive we
>>> could import it into read-only Datasette instance[0] — and that would
>>> likely be good enough.
>>>
>>> Can we move now?
>>>
>>> Thanks.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> [0]: I'd happily do this.
>>>
>>> --
>>> 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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com
>>> 
>>> .
>>>
>>> --
>>> 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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk
>>> 
>>> .
>>>
>> --
>> 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/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com
>> 
>> .
>>
> --
> 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

Re: rename internal SetPasswordForm.user into "instance" - or add it

2022-11-28 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

I don’t think it’s worth adding support for “instance”. The name “instance”
is used in generic mode view classes because they work with any kind of
object. Since the password change view knows it has a user, it can use the
more specific variable name.

You can add an “instance” property in your own subclass if that helps.

On Thu, 24 Nov 2022 at 10:59, Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi Django people,
>
> I'm having trouble using the built-in
> django.contrib.auth.forms.PasswordChangeForm (which is a SetPasswordForm
> child), called from PasswordChangeView.
>
> I know it is just a kind of example, as there is no actual documentation
> of the class, but should be usable stable too in projects, unmodified.
> It is mentioned in
>
> https://docs.djangoproject.com/en/4.1/topics/auth/default/#django.contrib.auth.forms.SetPasswordForm
> - but never explained, other than "A form that lets a user change their
> password without entering the old password." There is no official API.
>
> I use the view as base class for my own HTMX view, and with some other
> mixins (that auto-generate some user data) for all the sub views.
>
> For all the other forms in this group (which are ModelViews), "instance"
> is the parameter where the form binds it's internal model to.
> PasswordChangeForm is a Form (no ModelForm), as it does not make use of
> all the ModelForm automagic behaviour and creates 2 password fields
> itself. This is all fine. But in a row of forms each accepting
> "instance" as data source, this Form steps aside and uses "user" as
> argument.
>
> I can see a practicability in it, as it seems to be straightforward if
> you use this view alone - but it does not comply to other Django Forms,
> and has to be treated as "special" using get_form_kwargs() -> {"user":
> ...} in views using it.
>
>
> So my idea is (which may be bad - I could just copy that whole form+view
> and reproduce it with "instance" instead of "user", but DRY, ya know) :
> What would you say to renaming this "user" parameter into "instance" -
> it would make the view compatible to others, especially ModelForms.
>
> Drawbacks: It would break compatibility with every usage that directly
> calls the form with the "user" parameter. PasswordChangeView could be
> changed, so everyone using *that* would be save. only direct usage would
> be affected.
>
> But, would it be a possibility to stay compatible and add a second
> (optional) parameter named "instance"? The form could then just decide
> in __init__ if (user|instance) is present, and save the one that is
> present as self.user.
>
> This would ensure that the view could also call it with "instance", both
> would work.
>
> Anything speaking against that?
>
> Best regards,
>
> Christian
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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/a9b28310-88fc-912b-fe56-91589f50b7e1%40nerdocs.at
> .
>

-- 
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/CAMyDDM0c_1uWuKMe4Za7wArDWm0KjwvbxtWuAwvF0q7fzS6egw%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

2022-11-28 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

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 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 said it still supplies an
> easily searchable answer for "Django DATABASE_URL."
>
> Cheers,
> Tobias
>
>
> On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:
>
>> 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
>>
>> 
>>- instead adopt a behavior where Django will automatically handle a
>>string as an alternative to a configuration dictionary
>> (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
>>
>> 
>>
>> 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
>>  
>> 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

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-28 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

I am not sure the db level defaults PR is suitable for a GSoC project at
this point - it’s pretty well developed. I think it could do with some
review and testing form those who are interested.

On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> +1 from me on DB defaults (constraints too). I've worked on many systems
> where Django isn't the only place putting records into DBs and having DB
> level defaults and constraints fixes a lot of common issues with that.
> Currently I create an empty migrations to then add them in manually when
> required
>
>
> +1 from me on moving models between apps, though I know it can be a pain.
> Contacting and freelancing means you come across a lot of projects where
> models are seeming in the wrong app or where you want to consolidate apps
> and being able to move them cleaning would be a wonderful addition
> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>
>> I'd like to see database-level defaults supported in models and
>> migrations:
>>
>> https://code.djangoproject.com/ticket/470
>>
>> There's currently a PR open, which replaces an earlier 2020 PR
>>
>> https://github.com/django/django/pull/16092
>>
>> It would be a large benefit to those of us practicing continuous
>> deployment. It is also tricky enough that it would benefit from a full-time
>> effort to implement and refactor.
>>
>> - John
>>
>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson 
>> wrote:
>>
>>> Hi all.
>>>
>>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>>
>>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>>
>>> Django has participated many times, and it's been a real boon. Recent
>>> successes include:
>>>
>>> * The django-stubs mypy plugin.
>>> * The cross-db JSON field.
>>> * The Redis cache backend.
>>> * Per model-class (field instance) custom lookups
>>> * Setup of the django-asv benchmarking project.
>>> * ...
>>>
>>> Application deadline for Orgs is February 7. I'll begin working on it
>>> after the New Year.
>>>
>>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>>> Good Ideas List
>>> section.
>>>
>>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>>> complete.
>>>
>>> i.e. "short" or "long" projects.
>>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>>
>>> I'm writing here *to solicit input on project ideas*.
>>>
>>> I put "Technical Board?" in the subject because we're short a list of
>>> project
>>> ideas for the technical direction of Django going forward, and maybe
>>> thinking
>>> in terms of GSoC could be a way of bootstrapping that. The "?" is
>>> because that's not
>>> meant to exclude other input.
>>>
>>> Here's last year's list for reference:
>>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>>
>>> - Some of those were done: benchmarking (but that could be built on) and
>>> per-instance
>>>   field lookups.
>>>
>>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>>> agreement on scope,
>>>   so it's better to live as a third-party package.
>>>
>>> - I've tried to include folks from the wider ecosystem in previous
>>> years. Two years ago
>>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>>   applied in their own right, to great success. I'd like to offer that
>>> help
>>>   again to e.g. Jazzband or other established projects, assuming
>>> maintainers
>>>   feel they have the capacity to mentor. (It's a minor increment to my
>>> effort
>>>   for a good return I think.)
>>>
>>>
>>> No urgency but, can I ask you to put your grey cells into action? 
>>>
>>>
>>> Thanks.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> --
>>>
>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com
> 
>

Re: Technical Board vote on DEP 0012: The Steering Council

2022-11-28 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)

+1 from me

And +1 to using the forum in future

On Tue, 29 Nov 2022 at 00:23, charettes  wrote:

> +1 from me as well.
>
> Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
>
>> Hi All.
>>
>> Tom Forbes is currently unable to post to the Google Group here, due to
>> Currently Undiagnosed Google Account Weirdness™.
>>
>> For the record he's asked me to say that his vote is +1 in support of the
>> change, but I feel we should probably move voting to the forum because of
>> this.
>>
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Monday, 28 November 2022 at 09:52:35 UTC+1 f.apo...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> +1 from me, but I'd like to ask the wider community (ie DSF members)
>>> whether they support this change.
>>>
>>> While there has been some opposition on whether a change likes this will
>>> actually change things, I think that given the overall good reception of
>>> the proposal it is at least worth to try it.
>>>
>>> Cheers,
>>> Florian
>>> On Friday, November 25, 2022 at 10:04:36 AM UTC+1 Mariusz Felisiak wrote:
>>>
 Thanks!

 Reminder: according to DEP 10 voting will end on *December 2nd, 2022*
 *AoE* (members of the Technical Board may change their votes at any
 time prior to closing of the final voting period).

>>> --
> 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/378f606b-5d70-4013-a8d7-e8abb605f178n%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM1dGUTiKTezaYDbqF0PYv1%3DEf%2Ba_VqT1J%2ByP%2BbgbdePZQ%40mail.gmail.com.

Re: Technical Board vote on DEP 0012: The Steering Council

2022-11-28 Thread charettes

+1 from me as well.

Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :

> Hi All. 
>
> Tom Forbes is currently unable to post to the Google Group here, due to 
> Currently Undiagnosed Google Account Weirdness™. 
>
> For the record he's asked me to say that his vote is +1 in support of the 
> change, but I feel we should probably move voting to the forum because of 
> this. 
>
>
> Kind Regards,
>
> Carlton
>
>
> On Monday, 28 November 2022 at 09:52:35 UTC+1 f.apo...@gmail.com wrote:
>
>> Hi,
>>
>> +1 from me, but I'd like to ask the wider community (ie DSF members) 
>> whether they support this change.
>>
>> While there has been some opposition on whether a change likes this will 
>> actually change things, I think that given the overall good reception of 
>> the proposal it is at least worth to try it.
>>
>> Cheers,
>> Florian
>> On Friday, November 25, 2022 at 10:04:36 AM UTC+1 Mariusz Felisiak wrote:
>>
>>> Thanks!
>>>
>>> Reminder: according to DEP 10 voting will end on *December 2nd, 2022* 
>>> *AoE* (members of the Technical Board may change their votes at any 
>>> time prior to closing of the final voting period).
>>>
>>

-- 
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/378f606b-5d70-4013-a8d7-e8abb605f178n%40googlegroups.com.

Re: Integrate dj-database-url into Django

2022-11-28 Thread Curtis Maloney

I recently did a bit of an audit of "settings types" whilst preparing for an 
overhaul of django-classy-settings.

I found you could cover a majority of the common config types if you could 
somehow parse from an environ string the following (which closely aligns with 
django-environ):

+ str
+ int
+ bool
+ list/tuple
+ list/tuple
+ DB Config
+ Cache Config

The complicated ones being DB/Cache configs, and mostly because:
- whilst a basic URL suffices, there are lots of optional and sometimes nested 
options
- sqlite in-memory syntax is "special".

Alternatively, I've been telling myself for a while now I'd add 
django-compatible types to confucius, which uses a type annotations approach to 
env-driven settings.

Both support providing __dir__ and __getattr__ so you can plug them 
"transparently" into your settings.py whilst still benefiting from class 
features.


On Tue, 29 Nov 2022, at 09:20, James Bennett wrote:
> It feels like this needs to be a broader conversation about not just
> changing DATABASES to accept a URL, or integrating a particular
> database-settings project, but to re-think how Django does
> settings-from-environment as a whole.
> 
> When I'm setting up new Django-based projects, django-environ
> (https://pypi.org/project/django-environ/) is now one of the first
> packages I reach for, and it has a much more comprehensive set of
> helpers for configuring Django from environment variables and doing
> appropriate parsing and type casts.
> 
> There also is Pydantic's settings model
> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
> annotations to drive parsing/validation/type-casting and defaults to
> reading from environment variables.
> 
> I'd rather see some sort of comprehensive "make settings-from-env
> easier" in Django than one-off pieces like a database URL.
> 
> -- 
> 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/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com.
> 

--
C

-- 
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/a2aac2d9-d094-4df3-9b8e-df92ad9e1dc3%40app.fastmail.com.

Re: Integrate dj-database-url into Django

2022-11-28 Thread James Bennett

It feels like this needs to be a broader conversation about not just
changing DATABASES to accept a URL, or integrating a particular
database-settings project, but to re-think how Django does
settings-from-environment as a whole.

When I'm setting up new Django-based projects, django-environ
(https://pypi.org/project/django-environ/) is now one of the first
packages I reach for, and it has a much more comprehensive set of
helpers for configuring Django from environment variables and doing
appropriate parsing and type casts.

There also is Pydantic's settings model
(https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
annotations to drive parsing/validation/type-casting and defaults to
reading from environment variables.

I'd rather see some sort of comprehensive "make settings-from-env
easier" in Django than one-off pieces like a database URL.

-- 
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/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-28 Thread 'st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)

On this vein I'd also like to see DB Cascades implemented
https://code.djangoproject.com/ticket/21961


On Mon, 28 Nov 2022 at 18:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> +1 from me on DB defaults (constraints too). I've worked on many systems
> where Django isn't the only place putting records into DBs and having DB
> level defaults and constraints fixes a lot of common issues with that.
> Currently I create an empty migrations to then add them in manually when
> required
>
> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>
>> I'd like to see database-level defaults supported in models and
>> migrations:
>>
>> https://code.djangoproject.com/ticket/470
>>
>

-- 
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/CAJwKpyTqhMv6GATZ_wjMpv2YS%3D0aUV%3DNViAZRoi1KBRpePnwBg%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

+1 from me on DB defaults (constraints too). I've worked on many systems 
where Django isn't the only place putting records into DBs and having DB 
level defaults and constraints fixes a lot of common issues with that. 
Currently I create an empty migrations to then add them in manually when 
required


+1 from me on moving models between apps, though I know it can be a pain. 
Contacting and freelancing means you come across a lot of projects where 
models are seeming in the wrong app or where you want to consolidate apps 
and being able to move them cleaning would be a wonderful addition
On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:

> I'd like to see database-level defaults supported in models and migrations:
>
> https://code.djangoproject.com/ticket/470
>
> There's currently a PR open, which replaces an earlier 2020 PR
>
> https://github.com/django/django/pull/16092
>
> It would be a large benefit to those of us practicing continuous 
> deployment. It is also tricky enough that it would benefit from a full-time 
> effort to implement and refactor.
>
> - John
>
> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
> wrote:
>
>> Hi all. 
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced. 
>>
>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>
>> Django has participated many times, and it's been a real boon. Recent 
>> successes include: 
>>
>> * The django-stubs mypy plugin. 
>> * The cross-db JSON field. 
>> * The Redis cache backend. 
>> * Per model-class (field instance) custom lookups
>> * Setup of the django-asv benchmarking project. 
>> * ... 
>>
>> Application deadline for Orgs is February 7. I'll begin working on it 
>> after the New Year. 
>>
>> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
>> Good Ideas List
>> section. 
>>
>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to 
>> complete. 
>>
>> i.e. "short" or "long" projects. 
>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>
>> I'm writing here *to solicit input on project ideas*. 
>>
>> I put "Technical Board?" in the subject because we're short a list of 
>> project
>> ideas for the technical direction of Django going forward, and maybe 
>> thinking
>> in terms of GSoC could be a way of bootstrapping that. The "?" is because 
>> that's not 
>> meant to exclude other input.
>>
>> Here's last year's list for reference: 
>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>
>> - Some of those were done: benchmarking (but that could be built on) and 
>> per-instance 
>>   field lookups.
>>
>> - Rate-limiting is a no-go I think: we couldn't come to any decent 
>> agreement on scope, 
>>   so it's better to live as a third-party package. 
>>
>> - I've tried to include folks from the wider ecosystem in previous years. 
>> Two years ago 
>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>   applied in their own right, to great success. I'd like to offer that 
>> help
>>   again to e.g. Jazzband or other established projects, assuming 
>> maintainers
>>   feel they have the capacity to mentor. (It's a minor increment to my 
>> effort
>>   for a good return I think.)
>>
>>
>> No urgency but, can I ask you to put your grey cells into action? 
>>
>>
>> Thanks. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>> -- 
>>
> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-28 Thread 'John Whitlock' via Django developers (Contributions to Django itself)

I'd like to see database-level defaults supported in models and migrations:

https://code.djangoproject.com/ticket/470

There's currently a PR open, which replaces an earlier 2020 PR

https://github.com/django/django/pull/16092

It would be a large benefit to those of us practicing continuous
deployment. It is also tricky enough that it would benefit from a full-time
effort to implement and refactor.

- John

On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson 
wrote:

> Hi all.
>
> Google Summer of Code (GSoC) for 2023 has just been announced.
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent
> successes include:
>
> * The django-stubs mypy plugin.
> * The cross-db JSON field.
> * The Redis cache backend.
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project.
> * ...
>
> Application deadline for Orgs is February 7. I'll begin working on it
> after the New Year.
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a
> Good Ideas List
> section.
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
> complete.
>
> i.e. "short" or "long" projects.
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*.
>
> I put "Technical Board?" in the subject because we're short a list of
> project
> ideas for the technical direction of Django going forward, and maybe
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because
> that's not
> meant to exclude other input.
>
> Here's last year's list for reference:
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and
> per-instance
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent
> agreement on scope,
>   so it's better to live as a third-party package.
>
> - I've tried to include folks from the wider ecosystem in previous years.
> Two years ago
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
> 
> .
>

-- 
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/CAJ3y2QR7jg7cHWbTxEv-Pje9%3Dfxp7yiPBRuoxn1hAAX%3D8v0Vdg%40mail.gmail.com.

Re: Async wrappers in contrib packages

2022-11-28 Thread Jon Janzen

Hey Carlton,

There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view
> decorators to be applied directly to async views."
> I think this is likely the next step.
>
> There's a PR for that, which I think took a too complex approach (see
> discussion). A simpler (more inline) take be good to see.
>

Thanks, I saw this ticket but it didn't look relevant when I was skimming
the tracker. I'll take a closer look.

> My personal interest in this is about django.contrib.auth (login,
> authenticate, etc.)
>
> This was missing from the PR on #31949, so if you wanted to pick it up...
> 
>

I'll take a closer look, I think I might be able to do that :D


>
> (Not sure about the value of rewriting the built-in views though if that's
> what you're thinking of 樂)
>
> > ...and django.contrib.syndication (views.Feed)
>
> Not sure what you have in mind here. Perhaps explaining that in
> more detail would help?
> (I'm not immediately sure I see the benefit of async for the feed views?
> 樂)
>

Not for the view itself, but for individual fields that compose the Feed.

I want to define an async "item_categories" method when I subclass Feed due
to an async-only permissions system I have that is out-of-scope here, but
that isn't possible right now so I pre-compute each of these values and
pass in a composite object with the source object and item_categories
precomputed.

I would rather just declare an async function and let the framework figure
out how to resolve the values reasonably efficiently for me. I don't want
to pay the cost of async_to_sync for each item in the feed :/

I'm fine with setting this one aside, as I said I already have a
workaround. But I can file a ticket just to track this one?

 - Jon

-- 
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/CAP1wFiCp_y%3DVygQxmat-JVR2cr_LjGTKDyQ7rXtg3ERrzdfXXw%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

2022-11-28 Thread 'Tobias McNulty' via Django developers (Contributions to Django itself)

As someone who only just joined the forum -- I'm +1:

   - The forum has seen great adoption from what I can tell (nearly half
   the number of posts as django-developers during the same time period, not
   bad given the mailing list's head start in subscribers).
   - It seems beneficial to house future conversations in a single place,
   e.g., so members don't need to subscribe to both the mailing list and forum
   to get the full picture of current active development, set up two different
   sets of mail filters to tag things appropriately, etc...

Would the plan be to switch django-users as well? I think similar arguments
could be made for consolidating those...

(On the other hand, I see little value in switching django-announce and
django-updates, but I'm not necessarily opposed to it either, especially if
there's a way to import the subscribers to those lists...)

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
wrote:

> Hey Roger,
>
> Indeed it does. You can set up Email Mode (that may not be the actual
> name) and it’ll work just like a mailing list.
>
> You can also subscribe to just a particular category, so the Internals one
> would map to the discussion on this list.
>
>
>
> On Monday, 28 November 2022, Roger Gammans 
> wrote:
>
>> Hi
>>
>> I can't speak for others, but I personally STRONGLY value the fact that
>> this discussion happens in my inbox, not on yet another website.
>>
>> But perhaps the forum still supports this reading mode?
>>
>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> Given the issues with Tom's access to the mailing list here, and the fact
>> that the Forum has been active for a few years now, and is a great success,
>> I'd like to revisit whether we can move on-mass (all few of us :) over
>> there?
>>
>> We'd enjoy the benefits of a much nicer system. We'd not have issues such
>> as the current, and we'd be one less item in the pocket of a mega-corp.
>> (You can rank those as you will :)
>>
>> Initially when this can up (a long time ago) Andrew and Tom discussed
>> whether we could import the history here into the forum. I think that's
>> unnecessary. We can still access the history here (until such a day as
>> Google takes it away) at worst -- but, rather, if we can get an archive we
>> could import it into read-only Datasette instance[0] — and that would
>> likely be good enough.
>>
>> Can we move now?
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> [0]: I'd happily do this.
>>
>> --
>> 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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com
>> 
>> .
>>
>> --
>> 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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk
>> 
>> .
>>
> --
> 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/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com
> 
> .
>

-- 
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/CAMGFDKSKe7ZDDwiaBpKtsU0z582K482PFsSpNfTLSvb2B-L95A%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

2022-11-28 Thread Carsten Fuchs

Hello,

unfortunately, the emails sent by the forum have long prefixes in the subject 
lines, e.g.

[Django Forum] [Django Internals/ORM] Multiple Database Switching

That makes the messages easy to filter by mail client software, but comes at 
the cost of much visual clutter that is hard to parse, e. g. when the mail 
client presents messages hierarchically in a thread-based view.

Best regards,
Carsten



Am 28.11.22 um 15:05 schrieb Carlton Gibson:
> Hey Roger, 
> 
> Indeed it does. You can set up Email Mode (that may not be the actual name) 
> and it’ll work just like a mailing list. 
> 
> You can also subscribe to just a particular category, so the Internals one 
> would map to the discussion on this list. 
> 
> 
> 
> On Monday, 28 November 2022, Roger Gammans  > wrote:
> 
> Hi
> 
> I can't speak for others, but I personally STRONGLY value the fact that 
> this discussion happens in my inbox, not on yet another website. 
> 
> But perhaps the forum still supports this reading mode?

-- 
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/bdf1ecf8-fc09-af26-1f9a-978b7bafcf29%40cafu.de.

Re: Can we move the activity on this list to the Forum now?