Re: Ideas for a new DEP on long-term Django API compatibility

[Luke Plant]

Hi Pascal,

I know this is a very late reply, but there have been some things going 
round my head that I thought I should get down.


*First,* some positive changes I think we can make from your suggestions:

1. I think in our release notes, for breaking changes that might need 
some justification, we should link to the tickets and/or django-devs 
discussions behind them. Adding full reasoning in the notes themselves 
would likely bloat them far too much, but a link could be helpful for 
anything which is not obviously necessary.


2. We should change the wording in our API stability docs 
, which 
does indeed initially sound like a promise never to break working code 
that follows docs:


   Django promises API stability and forwards-compatibility since
   version 1.0.

We do have this line later on:

   If, for some reason, an API declared stable must be removed or
   replaced, it will be declared deprecated but will remain in the API
   for at least two feature releases. Warnings will be issued when the
   deprecated method is called.

But we do make changes at a rate faster than that document would make 
you think.


I suggest that as a contrast to the existing text on that page, we also 
point out that we are continually improving Django, and have a 
"(eventually) one way to do it" policy regarding how we plan APIs, which 
means we will remove old things, while always providing better 
alternatives. I'm happy to write a patch for this.


*Second,* there were things I wanted to say that might be useful to you 
(Pascal) in understanding why you are not likely to get very far with 
your current approach.


Your exaggerated tone is not likely to help you. You talk about Django's 
compatibility breakages as "/ruining the day of thousands of anonymous 
plugin/website maintainers all over the world/". When we make these kind 
of changes, we always do it with very clear and detailed upgrade notes, 
and almost always with several releases emitting deprecation warnings, 
as per our policy. And no-one is forced to upgrade immediately. Those 
who value stability above other things can use LTS, which gives them a 
*3 year release cadence,* not 8 months, which is far from excessively 
fast compared to other projects.


My involvement in Django these days is primarily not as a core 
contributor, but as a user and library maintainer, and I've also 
contributed many patches to different 3rd party Django projects to fix 
them for Django upgrades. The impression that you give of Django being a 
continuously shifting sand is very far from my experience. The core 
features and structure of Django have remained remarkably stable over 
its history. A few import changes here and there are very easy to fix 
(and, more importantly, noisy and easy to diagnose), and other changes 
are usually straightforward. Normally upgrades to libraries I maintain 
to support the latest Django version require very little work, sometimes 
zero, and often I'm able to support 4 or 5 Django versions without a 
problem. Using something like django-compat-patcher, or some of the 
other similar libraries, would add more complexity than the few lines of 
code I need otherwise.


Even larger, more complex Django projects like Mezzanine, which use 
quite a few hacks and internals, are often able to span across two LTS 
versions.


With all this in mind, it's difficult to see how we are making so many 
people's lives miserable.


Instead of debating in abstract, or answering your points one by one, I 
thought a few illustrations might help you see the benefits of Django's 
approach. The first is the longest, it might be of historical interest 
to others.



   1. A 14 year old Django project

I started work on my first Django project in September 2005 
, 
and it went live in March 2006. It has been running continuously since 
then - perhaps by now it can claim to be one of the oldest continuously 
running Django sites? I'd be interested to know if anyone can beat it...


Here's a snippet from one of my models.py nearly 14 years ago:


   class Message(meta.Model):
    fromUser = meta.ForeignKey(User,
        verbose_name="from user",
        related_name="messageSent"
    )
    toUser = meta.ForeignKey(User,
        verbose_name="to user",
        related_name="messageReceived")
    time = meta.DateTimeField("At")
    text = meta.TextField("Message")
    box = meta.PositiveSmallIntegerField("Message box",
        choices = MESSAGE_BOXES)

    def __repr__(self):

        #return str(self.id)
        return "[" + str(self.id) + "] to " + repr(self.get_toUser())  + " from 
" + repr(self.get_fromUser())

    class META:

        admin = meta.Admin(
            list_display = ('toUser', 'fromUser', 'time')
        )
  

Django security releases issued: 2.2.4, 2.1.11, and 1.11.23.

[Carlton Gibson]

Today the Django team issued 2.2.4, 2.1.11, and 1.11.23 as part of our security 
process. These releases address security issues, and we encourage all users to 
upgrade as soon as possible:

https://www.djangoproject.com/weblog/2019/aug/01/security-releases/

-- 
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/07D281DE-5051-4743-9D24-CCCB0A54F77F%40gmail.com.

Django Websocket Implementation Request

[Confi Yobo]

This might be a little redundant as you would say but i see importance in
it.

Django should come chipped in with websocket implementation rather
developers using third party libraries like django-channels which are
difficult and most at times have poor documentation. I have seen many cases
where developers want to build an application that requires websocket they
use another web framework.

So in my opinion and that of few other developers i'v  seen i think
websocket feature should be added to django out of the box(something like
socket.io would make a lot of sense).

-- 
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/CAD9uRzdHaQJdo3%2BBt%2BDzGfadvLTK%2B8gC7r2A75Q8a4L3dkN42Q%40mail.gmail.com.

Re: Django Websocket Implementation Request

[Carlton Gibson]

Hmmm. I guess Channel is doing more than just websockets, but I've always 
thought it had good docs... Anyhow...

We'll see how the Async work goes, but a lot of channel will end up being 
absorbed into Django itself. What, at this point, I guess that will leave 
is "just" the websocket bit. (Maybe the Channel Layers bit... too but maybe 
that would/could be separate.) Hopefully this'll make it more focused and 
easier to follow

But... I think websockets haven't turned out to be the One True Hammer 
people thought. (They're not that popular actually, it seems...) So I'm not 
sure we'd include support in core (vs keeping it in the third-party 
package.) 

I guess something to revisit after 3.0. 

Kind Regards,

Carlton


On Thursday, 1 August 2019 15:09:21 UTC+2, Confi Yobo wrote:
>
> This might be a little redundant as you would say but i see importance in 
> it.
>
> Django should come chipped in with websocket implementation rather 
> developers using third party libraries like django-channels which are 
> difficult and most at times have poor documentation. I have seen many cases 
> where developers want to build an application that requires websocket they 
> use another web framework.
>
> So in my opinion and that of few other developers i'v  seen i think 
> websocket feature should be added to django out of the box(something like 
> socket.io would make a lot of sense).
>

-- 
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/c561814d-941c-446f-8707-c2ef1ce8170e%40googlegroups.com.

Re: Django Websocket Implementation Request

[Confi Yobo]

Please consider it, cause the procedures of using third party websocket
library (mostly for production) is cumbersome

On Thu, Aug 1, 2019 at 2:22 PM Carlton Gibson 
wrote:

> Hmmm. I guess Channel is doing more than just websockets, but I've always
> thought it had good docs... Anyhow...
>
> We'll see how the Async work goes, but a lot of channel will end up being
> absorbed into Django itself. What, at this point, I guess that will leave
> is "just" the websocket bit. (Maybe the Channel Layers bit... too but maybe
> that would/could be separate.) Hopefully this'll make it more focused and
> easier to follow
>
> But... I think websockets haven't turned out to be the One True Hammer
> people thought. (They're not that popular actually, it seems...) So I'm not
> sure we'd include support in core (vs keeping it in the third-party
> package.)
>
> I guess something to revisit after 3.0.
>
> Kind Regards,
>
> Carlton
>
>
> On Thursday, 1 August 2019 15:09:21 UTC+2, Confi Yobo wrote:
>>
>> This might be a little redundant as you would say but i see importance in
>> it.
>>
>> Django should come chipped in with websocket implementation rather
>> developers using third party libraries like django-channels which are
>> difficult and most at times have poor documentation. I have seen many cases
>> where developers want to build an application that requires websocket they
>> use another web framework.
>>
>> So in my opinion and that of few other developers i'v  seen i think
>> websocket feature should be added to django out of the box(something like
>> socket.io would make a lot of sense).
>>
> --
> 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/c561814d-941c-446f-8707-c2ef1ce8170e%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/CAD9uRzcpxHkhZ5hNUu1xF73nTF%3DpR_qmyV8nJweEvQmivz57KQ%40mail.gmail.com.

Re: Django Websocket Implementation Request

[Confi Yobo]

And socket.io kind of implementation is one thing developers from js like
us are missing in django.

On Thu, Aug 1, 2019 at 8:58 PM Confi Yobo  wrote:

> Please consider it, cause the procedures of using third party websocket
> library (mostly for production) is cumbersome
>
> On Thu, Aug 1, 2019 at 2:22 PM Carlton Gibson 
> wrote:
>
>> Hmmm. I guess Channel is doing more than just websockets, but I've always
>> thought it had good docs... Anyhow...
>>
>> We'll see how the Async work goes, but a lot of channel will end up being
>> absorbed into Django itself. What, at this point, I guess that will leave
>> is "just" the websocket bit. (Maybe the Channel Layers bit... too but maybe
>> that would/could be separate.) Hopefully this'll make it more focused and
>> easier to follow
>>
>> But... I think websockets haven't turned out to be the One True Hammer
>> people thought. (They're not that popular actually, it seems...) So I'm not
>> sure we'd include support in core (vs keeping it in the third-party
>> package.)
>>
>> I guess something to revisit after 3.0.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Thursday, 1 August 2019 15:09:21 UTC+2, Confi Yobo wrote:
>>>
>>> This might be a little redundant as you would say but i see importance
>>> in it.
>>>
>>> Django should come chipped in with websocket implementation rather
>>> developers using third party libraries like django-channels which are
>>> difficult and most at times have poor documentation. I have seen many cases
>>> where developers want to build an application that requires websocket they
>>> use another web framework.
>>>
>>> So in my opinion and that of few other developers i'v  seen i think
>>> websocket feature should be added to django out of the box(something like
>>> socket.io would make a lot of sense).
>>>
>> --
>> 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/c561814d-941c-446f-8707-c2ef1ce8170e%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/CAD9uRzdwK6Luj9cKZN70FgRRRO%2BtrybZ16XwB-FjWiPXZu9Eqw%40mail.gmail.com.

Re: Django Websocket Implementation Request

[Andrew Godwin]

Unfortunately, from my perspective, websocket support is tricky enough that
it's at least not on the short-term plan to bake into Django; it's used by
only a small fraction of our users, and the Channels project is an official
Django project, so it's as close as we can get so far. Future Django
versions with async support will shrink Channels down significantly, and
remove the need for it to be hosted differently, but the plan is still to
have it as a separate package - we may write about it in the official docs,
though.

socket.io is even harder as it's fundamentally hard to scale - it needs
stateful storage to aid in transferring connections, and this means it's
really hard to have a single method that will work for everyone. Having
"one right way to do it" is sort of a necessary prerequisite to having
something in Django, and I just don't feel like it's there.

Andrew

On Fri, Aug 2, 2019 at 6:00 AM Confi Yobo  wrote:

> And socket.io kind of implementation is one thing developers from js like
> us are missing in django.
>
> On Thu, Aug 1, 2019 at 8:58 PM Confi Yobo  wrote:
>
>> Please consider it, cause the procedures of using third party websocket
>> library (mostly for production) is cumbersome
>>
>> On Thu, Aug 1, 2019 at 2:22 PM Carlton Gibson 
>> wrote:
>>
>>> Hmmm. I guess Channel is doing more than just websockets, but I've
>>> always thought it had good docs... Anyhow...
>>>
>>> We'll see how the Async work goes, but a lot of channel will end up
>>> being absorbed into Django itself. What, at this point, I guess that will
>>> leave is "just" the websocket bit. (Maybe the Channel Layers bit... too but
>>> maybe that would/could be separate.) Hopefully this'll make it more focused
>>> and easier to follow
>>>
>>> But... I think websockets haven't turned out to be the One True Hammer
>>> people thought. (They're not that popular actually, it seems...) So I'm not
>>> sure we'd include support in core (vs keeping it in the third-party
>>> package.)
>>>
>>> I guess something to revisit after 3.0.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Thursday, 1 August 2019 15:09:21 UTC+2, Confi Yobo wrote:

 This might be a little redundant as you would say but i see importance
 in it.

 Django should come chipped in with websocket implementation rather
 developers using third party libraries like django-channels which are
 difficult and most at times have poor documentation. I have seen many cases
 where developers want to build an application that requires websocket they
 use another web framework.

 So in my opinion and that of few other developers i'v  seen i think
 websocket feature should be added to django out of the box(something like
 socket.io would make a lot of sense).

>>> --
>>> 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/c561814d-941c-446f-8707-c2ef1ce8170e%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/CAD9uRzdwK6Luj9cKZN70FgRRRO%2BtrybZ16XwB-FjWiPXZu9Eqw%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/CAFwN1upE%2BikHmiserS%3DKKQsT_xu5wZO14jUaDUCqVXZ_43WZOQ%40mail.gmail.com.

Re: Django Websocket Implementation Request

[Confi Yobo]

So it should not be expected in future release?

On Thu, Aug 1, 2019 at 9:14 PM Andrew Godwin  wrote:

> Unfortunately, from my perspective, websocket support is tricky enough
> that it's at least not on the short-term plan to bake into Django; it's
> used by only a small fraction of our users, and the Channels project is an
> official Django project, so it's as close as we can get so far. Future
> Django versions with async support will shrink Channels down significantly,
> and remove the need for it to be hosted differently, but the plan is still
> to have it as a separate package - we may write about it in the official
> docs, though.
>
> socket.io is even harder as it's fundamentally hard to scale - it needs
> stateful storage to aid in transferring connections, and this means it's
> really hard to have a single method that will work for everyone. Having
> "one right way to do it" is sort of a necessary prerequisite to having
> something in Django, and I just don't feel like it's there.
>
> Andrew
>
> On Fri, Aug 2, 2019 at 6:00 AM Confi Yobo  wrote:
>
>> And socket.io kind of implementation is one thing developers from js
>> like us are missing in django.
>>
>> On Thu, Aug 1, 2019 at 8:58 PM Confi Yobo  wrote:
>>
>>> Please consider it, cause the procedures of using third party websocket
>>> library (mostly for production) is cumbersome
>>>
>>> On Thu, Aug 1, 2019 at 2:22 PM Carlton Gibson 
>>> wrote:
>>>
 Hmmm. I guess Channel is doing more than just websockets, but I've
 always thought it had good docs... Anyhow...

 We'll see how the Async work goes, but a lot of channel will end up
 being absorbed into Django itself. What, at this point, I guess that will
 leave is "just" the websocket bit. (Maybe the Channel Layers bit... too but
 maybe that would/could be separate.) Hopefully this'll make it more focused
 and easier to follow

 But... I think websockets haven't turned out to be the One True Hammer
 people thought. (They're not that popular actually, it seems...) So I'm not
 sure we'd include support in core (vs keeping it in the third-party
 package.)

 I guess something to revisit after 3.0.

 Kind Regards,

 Carlton


 On Thursday, 1 August 2019 15:09:21 UTC+2, Confi Yobo wrote:
>
> This might be a little redundant as you would say but i see importance
> in it.
>
> Django should come chipped in with websocket implementation rather
> developers using third party libraries like django-channels which are
> difficult and most at times have poor documentation. I have seen many 
> cases
> where developers want to build an application that requires websocket they
> use another web framework.
>
> So in my opinion and that of few other developers i'v  seen i think
> websocket feature should be added to django out of the box(something like
> socket.io would make a lot of sense).
>
 --
 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/c561814d-941c-446f-8707-c2ef1ce8170e%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/CAD9uRzdwK6Luj9cKZN70FgRRRO%2BtrybZ16XwB-FjWiPXZu9Eqw%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/CAFwN1upE%2BikHmiserS%3DKKQsT_xu5wZO14jUaDUCqVXZ_43WZOQ%40mail.gmail.com
> 
> .
>

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