Re: Potential way forward for DATABASE_URL

[Carlton Gibson]

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

[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

[Carlton Gibson]

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

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

['Kye Russell' via Django developers (Contributions to Django itself)]

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?

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

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

['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.

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

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

[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

[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

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

[Carlton Gibson]

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.

['st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)]

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

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

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

['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?

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

[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?
>
> 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.

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

[Roger Gammans]

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.

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

[Carlton Gibson]

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.

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

[Carlton Gibson]

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/a2f62728-33b0-43e7-8fcc-696b7e6fac82n%40googlegroups.com.

Re: Integrate dj-database-url into Django

[Carlton Gibson]

Hey Tobias.

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

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

>From my glance, all positive points:

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

Given that it's a single import I might still lean towards seeing it as an
external package, at least for a cycle, so unknowns that come up can be
resolved, and folks on an older LTS can opt-in early, etc.
(But that's not a point of religion.)

Kind Regards,

Carlton

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

> Hi Carlton,
>
> Responses inline below:
>
> On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson 
> wrote:
>
>> Hi Raphael, thanks for picking this up.
>>
>> Looking at the history here, particularly the discussion here
>> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
>> but there are others, the reason this hasn't already happened is that if
>> we're going to merge this into core it would be nice (required?) to handle
>> extra cases than (to paraphrase) "just what Heroku expects".
>>
>> It doesn't look like anyone has sat down to spec out exactly what that
>> means, but there seem to be plenty of thoughts in the discussion.  ... 樂
>>
>> JKM's comment on the thread there is representative of the general
>> thought:
>>
>> > I suspect this is a "good enough is good enough" situation. Something
>> like what
>> Raffaele is talking about, or dsnparse, or whatever would probably be
>> ideal. And
>> for something to be merged into core, I think it'd need to be a more full
>> solution than just dj-database-url.
>>
>
> Isn't this already a more full solution insofar as it supports setting
> CACHES as well? This may or may not be correct, but I read the history a
> little differently, more that "life happens" and no one quite found the
> energy to push the current solution over the finish line (I empathize
> completely!).
>
> The trouble with merging a suboptimal solution is that once it's in, it's 
> *very
>> hard* to change. We have the whole API stability policy to contend with
>> (and rightly so).
>> We bring in a half-baked solution; likely "recommend" it (for some value
>> of that) and then face a long stream of difficult adjustments whilst we try
>> and accommodate the necessary adjustments.
>>
>
> I agree 100%, and I feel like we can and will take this into consideration
> sufficiently as we refine the current solution, if we continue down this
> path.
>
>  Given that dj-database-url is stable, a single line install, and (most
>> importantly) not being developed to try and accommodate the issues that
>> stopped it just being merged into core already, I think it should continue
>> to live as a third-party package.
>>
>> The place for the development to happen is in dj-database-url or a
>> successor package. (The first step would be a Roadmap drawn from the
>> historical discussion.)
>> Once (if) that gets to the point where it clearly addresses the 90% of
>> needs, then there's a case for adding it to core. I don't think we can just
>> push forward given that nothing changed in the last few years.
>>
>
> Could you (or others) provide some examples of the needs this solution
> doesn't address (not necessarily complete, just to give an idea)?
>
> Many thanks,
> Tobias
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyQE%2BCGB0YtFF_%3DKbSwDt-AbvNQO4CHTdBBA5XUaHECTOA%40mail.gmail.com.

Re: Integrate dj-database-url into Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Carlton,

Responses inline below:

On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson 
wrote:

> Hi Raphael, thanks for picking this up.
>
> Looking at the history here, particularly the discussion here
> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
> but there are others, the reason this hasn't already happened is that if
> we're going to merge this into core it would be nice (required?) to handle
> extra cases than (to paraphrase) "just what Heroku expects".
>
> It doesn't look like anyone has sat down to spec out exactly what that
> means, but there seem to be plenty of thoughts in the discussion.  ... 樂
>
> JKM's comment on the thread there is representative of the general
> thought:
>
> > I suspect this is a "good enough is good enough" situation. Something
> like what
> Raffaele is talking about, or dsnparse, or whatever would probably be
> ideal. And
> for something to be merged into core, I think it'd need to be a more full
> solution than just dj-database-url.
>

Isn't this already a more full solution insofar as it supports setting
CACHES as well? This may or may not be correct, but I read the history a
little differently, more that "life happens" and no one quite found the
energy to push the current solution over the finish line (I empathize
completely!).

The trouble with merging a suboptimal solution is that once it's in, it's *very
> hard* to change. We have the whole API stability policy to contend with
> (and rightly so).
> We bring in a half-baked solution; likely "recommend" it (for some value
> of that) and then face a long stream of difficult adjustments whilst we try
> and accommodate the necessary adjustments.
>

I agree 100%, and I feel like we can and will take this into consideration
sufficiently as we refine the current solution, if we continue down this
path.

 Given that dj-database-url is stable, a single line install, and (most
> importantly) not being developed to try and accommodate the issues that
> stopped it just being merged into core already, I think it should continue
> to live as a third-party package.
>
> The place for the development to happen is in dj-database-url or a
> successor package. (The first step would be a Roadmap drawn from the
> historical discussion.)
> Once (if) that gets to the point where it clearly addresses the 90% of
> needs, then there's a case for adding it to core. I don't think we can just
> push forward given that nothing changed in the last few years.
>

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

Many thanks,
Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com.

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

[Tom Carrick]

Just a small spinoff idea from Adam's suggestion on django-stubs. There is
another package, django-types that started as a fork of django-stubs and
was originally intended to be merged back into it. It removes the need to
use any mypy plugins, making it possible to use type checkers other than
mypy, such as Pyrite, Pyre, etc.  However, django-types isn't nearly as
actively maintained and having competing type stubs libraries is quite
annoying as they each get fixes for different issues, leaving neither in
especially good shape, IMO. Although the work has previously been done I
think there is enough work there detangling it and getting a PR to a
mergeable state for a short project.

Tom


On Sat, 26 Nov 2022 at 17:02, Shai Berger  wrote:

> Hi,
>
> Adding to the above, I have two migration-related ideas.
>
> The first is quite down-to-earth: Support for moving models between
> apps. This is a long-standing problem, esp. in enterprise-y or just
> long-running projects. I have expressed my dissatisfaction with the
> current state of things a couple of years ago[1], and maybe it's time
> to change that.
>
> The second is a bit of a pie-in-the-sky: Allow auto-detection of custom
> migration operations. The auto-detector has its change-detection mostly
> hard-coded into it[2], and it doesn't seem easy or even possible to
> allow third-party code to intervene. But I dream...
>
> Note: These two are quite independent. Auto-detection of the fact that
> a model has moved between apps is not required, supporting such moves
> with flags to makemigrations or even a dedicated management-command
> would be completely satisfactory as far as I'm concerned.
>
> Thanks,
> Shai.
>
>
> [1] https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
> [2]
> https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104
>
> --
> 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/20221126180231.372b01a2.shai%40platonix.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/CAHoz%3DMbM1M26%2BtrKwX7CoAK_VmORNQGLMLCn_WC5vhAP4PuU4g%40mail.gmail.com.

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

[Florian Apolloner]

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/77e508b4-8264-4997-b531-5da0416b6171n%40googlegroups.com.

Re: Integrate dj-database-url into Django

[Carlton Gibson]

I see you posted afresh in the other thread, addressing some of the points
here. C.


On Mon, 28 Nov 2022 at 08:39, Carlton Gibson 
wrote:

> Hi Raphael, thanks for picking this up.
>
> Looking at the history here, particularly the discussion here
> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
> but there are others, the reason this hasn't already happened is that if
> we're going to merge this into core it would be nice (required?) to handle
> extra cases than (to paraphrase) "just what Heroku expects".
>
> It doesn't look like anyone has sat down to spec out exactly what that
> means, but there seem to be plenty of thoughts in the discussion.  ... 樂
>
> JKM's comment on the thread there is representative of the general
> thought:
>
> > I suspect this is a "good enough is good enough" situation. Something
> like what
> Raffaele is talking about, or dsnparse, or whatever would probably be
> ideal. And
> for something to be merged into core, I think it'd need to be a more full
> solution than just dj-database-url.
>
> The trouble with merging a suboptimal solution is that once it's in, it's 
> *very
> hard* to change. We have the whole API stability policy to contend with
> (and rightly so).
> We bring in a half-baked solution; likely "recommend" it (for some value
> of that) and then face a long stream of difficult adjustments whilst we try
> and accommodate the necessary adjustments.
>
> Given that dj-database-url is stable, a single line install, and (most
> importantly) not being developed to try and accommodate the issues that
> stopped it just being merged into core already, I think it should continue
> to live as a third-party package.
>
> The place for the development to happen is in dj-database-url or a
> successor package. (The first step would be a Roadmap drawn from the
> historical discussion.)
> Once (if) that gets to the point where it clearly addresses the 90% of
> needs, then there's a case for adding it to core. I don't think we can just
> push forward given that nothing changed in the last few years.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sun, 27 Nov 2022 at 20:40, Raphael G  wrote:
>
>> Alright, I tried to revive Tom Forbe's work on this in
>> https://github.com/django/django/pull/16331
>>
>> My honest feeling here is that if Django existed just for me, I would
>> really just want to get this pulled in as an option, and trying to increase
>> the scope beyond "given a URL, get a dictionary of settings" is a tarpit
>> that is not worth venturing into in a first merge. Though it's definitely a
>> tarpit worth venturing into as a future step!
>>
>> So my strategy here was to try and get this as close to mergeable as
>> possible, with as few points of discussion needed as possible. I tried to
>> document what Tom did, more or less disregarded the idea of providing DSN
>> support in settings, and for memcache avoided blessing an "official"
>> backend. The main thing should be that if people google Django DATABASE_URL
>> there should be a good answer in the docs, IMO.
>>
>> As someone who's dealt with custom backends in various parts of Django,
>> and with libs, I think Tom's simple registry pattern for custom protocols
>> is more than sufficient for library writers.
>>
>> Documentation is minimal, but exists. While I basically expect people
>> writing custom DB backends or cache backends to directly look at the
>> source, at the very least we are pointing to the existence of functions for
>> registration in the docs in this PR.
>>
>> I'm sure we all have these simple projects that really don't need to do
>> much, we all have been pulling in dj_database_url on the side to get this
>> and feeling a bit off about it, so let's try and get that use case handled
>> in a way that doesn't prevent further niceness in the future!
>>
>> Raphael
>> On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote:
>>
>>> Hi all,
>>> I'm working on https://github.com/django/django/pull/10786 (which is a
>>> port of https://pypi.org/project/django-service-urls/ , which is a
>>> 'fork/rewrite' of Tom PR).
>>> I need to (re)read all these emails to find ideas to improve the
>>> PR/package.
>>>
>>> On Sat, Jul 28, 2018 at 9:44 PM Tom Forbes  wrote:
>>>
 So in the PR I proposed I only bits I took verbatim from
 dj-database-url are the tests. The rest is re-implemented. I think it's a
 pretty good POC but I haven't touched it in a while.

 In any case we have to implement our own parsing for backends that do
 not support passing in a URL to the connection library.

 Making postgres skip our parsing step and passing it in directly is an
 implementation detail and there are much more important questions around
 the API design to answer before this has any chance of being included.

 On Sat, 28 Jul 2018, 12:57 Maciej Urbański,  wrote:

> I would agree that DSN support seems like a nicer alternative to just
> copying 

Re: Async wrappers in contrib packages

[Carlton Gibson]

Hi Jon.

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.

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

(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? 樂)

Kind Regards,

Carlton


On Sun, 27 Nov 2022 at 23:02, Jon Janzen  wrote:

> Hey everyone,
>
> Sorry if I'm not following correct protocol on this or if this has already
> been discussed elsewhere, but is there any consensus about (or needed for)
> creating async versions of contrib packages?
>
> My personal interest in this is about django.contrib.auth (login,
> authenticate, etc.) and django.contrib.syndication (views.Feed) but I would
> guess this sort of work would fall under a general policy.
>
> I read DEP009
>  and
> didn't see any discussion of this topic, nor could I find any discussions
> on the ticket tracker (my skills using the tracker are limited). I could
> only find 2 files mentioning "async" in django/contrib/ (git grep "async"
> django/contrib | grep "\.py:"):
>
> * django/contrib/contenttypes/fields.py (added by me recently
> ,
> a bug fix )
> * django/contrib/staticfiles/handlers.py (added as part of standing up
> async support
> 
> )
>
> Has there been any consensus about this? If I'm interested in async
> versions of functions/features in contrib packages should I just file
> tickets, or is this something that might need a DEP first?
>
> Again, sorry if I'm barking up the wrong tree. It's not my intention to
> waste anyone's time!
>
> --
> 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/70e80f26-e1fa-4aa9-a3a8-0d7dc38752c3n%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/CAJwKpyRdOHcNymeAoQceMeiog%2Bum8cUJVKsXB6uyhTajmbbwxA%40mail.gmail.com.