Re: Consider making asgi_rabbitmq an official Django project.

[Artem Malyshev]

I agree that making a separate technical team for channels will help 
organization process. I think that moving Daphne and asgiref will result in 
a really bad situation. Probably we will end up with unmaintained ASGI 
infrastructure. So Channels won't work either because the underlying layer 
of technology is broken.

I'm glad to join ASGI/Channels technical team regardless of asgi_rabbitmq 
inclusion. I have few ideas I want to see in Channels (like check framework 
integration, third-party Consul integration and a few more). Also, I want 
to help with existing issues. But as a sole entrepreneur, I usually 
unavailable during new project search (like now). So if daily 
responsiveness isn't the case, please consider me as the technical team 
member.

Regards, Artem.

On Thursday, June 15, 2017 at 6:06:15 AM UTC+3, Andrew Godwin wrote:
>
> The other channels projects are currently maintained by me and me alone 
> (some people were initially helping but have since got busy with other 
> things), which is an untenable position and one I am trying to seek help to 
> fix but have not succeeded so far in doing so.
>
> This is one of the reasons I don't want Django to take on more; we should 
> get our current house in order before we expand. At the current rate I 
> expect I'll burn out on unpaid Channels work early next year (some stuff I 
> can maintain/improve at work as we use it there, but community support and 
> issue responding is not one of those things).
>
> There is an argument to be made for un-parenting the daphne, asgiref, 
> asgi_redis and asgi_ipc projects from Django and just leaving Channels, but 
> that would result in an even worse situation (IMO) of having third-party 
> dependencies that have even less visibility.
>
> Andrew
>
> On Thu, Jun 15, 2017 at 12:42 AM, Tim Graham  > wrote:
>
>> From my perspective, there's been little visibility into how things are 
>> going with the other channels related official projects. Who are the other 
>> maintainers there? I would present this question to those people (hopefully 
>> there are some others by now?) rather than to the Django maintainers which 
>> is who I think of when you say "Django core" (a term we're trying to 
>> replace with "Technical team" and "Technical advisory team" [0]). 
>> Organizationally, I think it could be nice if channels has its own 
>> technical team rather than giving the impression that the Django 
>> maintainers are also stewarding all other official projects.
>>
>> [0] https://www.djangoproject.com/foundation/teams/
>>
>> On Tuesday, June 13, 2017 at 9:22:30 PM UTC-4, Andrew Godwin wrote:
>>>
>>> Hi Artem,
>>>
>>> Thanks for adding the comments - it does look better. The thing I would 
>>> like to have is more feedback from Django core about this; I've not heard 
>>> anyone's opinion but mine, and I am not entirely sure if we should do this 
>>> (I am also not entirely sure asgi_ipc should be a Django project some days).
>>>
>>> Andrew
>>>
>>> On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev  
>>> wrote:
>>>
 Hi Andrew,

 I'm very glad to hear it's considered useful. If you look at recent 
 master you can see that I've added documentation and comments to the code.

 Exact commit 
 https://github.com/proofit404/asgi_rabbitmq/commit/9add0b8fec10ff93f8a813838f4f8ad87fde7e1f

 Also, I found the second maintainer for the project, Andrii 
 Soldatenko.  He is in the mail carbon copy.

 Any insights what to do next?

 Regards, Artem.

 On Sunday, June 11, 2017 at 4:08:20 AM UTC+3, Andrew Godwin wrote:
>
> Hi Artem,
>
> I know we've discussed this privately but I want to put some things on 
> the public list (and get at least one reply).
>
> My view is that it would be useful to have it maintained, but I do not 
> personally have the spare time to help maintain it, so it would need at 
> least one other person to help you maintain it before we could accept it 
> (they would not have to be existing core, but would need some history of 
> open-source maintenance)
>
> The other thing would be to see the existing code have more comments 
> and documentation; currently it has very few comments, in particular.
>
> Andrew
>
> On Thu, Jun 8, 2017 at 9:39 PM, Artem Malyshev  
> wrote:
>
>> Hi everyone,
>>
>> asgi_rabbitmq is Channels layer on top of RabbitMQ.  It was 
>> originally developed as part of Mozilla funding program.
>>
>> I've complete few major milestones after this.  Now it's used in few 
>> production systems.  It implements the ASGI specification exactly and 
>> performs well.
>>
>> I want to make asgi_rabbitmq an official Django project.
>>
>> Reasons why I want this happens:
>>
>> - It will be widely used.  Major changes in the Channels and ASGI 
>> will 

Re: Consider making asgi_rabbitmq an official Django project.

[Andrew Godwin]

The other channels projects are currently maintained by me and me alone
(some people were initially helping but have since got busy with other
things), which is an untenable position and one I am trying to seek help to
fix but have not succeeded so far in doing so.

This is one of the reasons I don't want Django to take on more; we should
get our current house in order before we expand. At the current rate I
expect I'll burn out on unpaid Channels work early next year (some stuff I
can maintain/improve at work as we use it there, but community support and
issue responding is not one of those things).

There is an argument to be made for un-parenting the daphne, asgiref,
asgi_redis and asgi_ipc projects from Django and just leaving Channels, but
that would result in an even worse situation (IMO) of having third-party
dependencies that have even less visibility.

Andrew

On Thu, Jun 15, 2017 at 12:42 AM, Tim Graham  wrote:

> From my perspective, there's been little visibility into how things are
> going with the other channels related official projects. Who are the other
> maintainers there? I would present this question to those people (hopefully
> there are some others by now?) rather than to the Django maintainers which
> is who I think of when you say "Django core" (a term we're trying to
> replace with "Technical team" and "Technical advisory team" [0]).
> Organizationally, I think it could be nice if channels has its own
> technical team rather than giving the impression that the Django
> maintainers are also stewarding all other official projects.
>
> [0] https://www.djangoproject.com/foundation/teams/
>
> On Tuesday, June 13, 2017 at 9:22:30 PM UTC-4, Andrew Godwin wrote:
>>
>> Hi Artem,
>>
>> Thanks for adding the comments - it does look better. The thing I would
>> like to have is more feedback from Django core about this; I've not heard
>> anyone's opinion but mine, and I am not entirely sure if we should do this
>> (I am also not entirely sure asgi_ipc should be a Django project some days).
>>
>> Andrew
>>
>> On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> I'm very glad to hear it's considered useful. If you look at recent
>>> master you can see that I've added documentation and comments to the code.
>>>
>>> Exact commit https://github.com/proofit404/asgi_rabbitmq/commit/9a
>>> dd0b8fec10ff93f8a813838f4f8ad87fde7e1f
>>>
>>> Also, I found the second maintainer for the project, Andrii Soldatenko.
>>> He is in the mail carbon copy.
>>>
>>> Any insights what to do next?
>>>
>>> Regards, Artem.
>>>
>>> On Sunday, June 11, 2017 at 4:08:20 AM UTC+3, Andrew Godwin wrote:

 Hi Artem,

 I know we've discussed this privately but I want to put some things on
 the public list (and get at least one reply).

 My view is that it would be useful to have it maintained, but I do not
 personally have the spare time to help maintain it, so it would need at
 least one other person to help you maintain it before we could accept it
 (they would not have to be existing core, but would need some history of
 open-source maintenance)

 The other thing would be to see the existing code have more comments
 and documentation; currently it has very few comments, in particular.

 Andrew

 On Thu, Jun 8, 2017 at 9:39 PM, Artem Malyshev 
 wrote:

> Hi everyone,
>
> asgi_rabbitmq is Channels layer on top of RabbitMQ.  It was originally
> developed as part of Mozilla funding program.
>
> I've complete few major milestones after this.  Now it's used in few
> production systems.  It implements the ASGI specification exactly and
> performs well.
>
> I want to make asgi_rabbitmq an official Django project.
>
> Reasons why I want this happens:
>
> - It will be widely used.  Major changes in the Channels and ASGI will
> take this library into account.
>
> We need:
>
> - Discuss if it's interesting at all for Django project.  Find at
> least one more person who understands library code.  Documentation has a
> comprehensive chapter about internal design and implementation.
>
> Conditions under which I prefer it happens:
>
> - I want to keep commit access for this repository for future
> development and fixes.  - I'll keep it up to date with coming channels
> releases.  - I'll do initial preparation steps for code transfer like code
> clean up if necessary.  But I need receive some comments after code 
> review.
>
> Project repository: https://github.com/proofit404/asgi_rabbitmq
>
> Regards, Artem.
>
> --
> 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

Re: Admin browser support policy

[Tim Graham]

Django 1.11 dropped support for IE8 and below as those browsers are end of 
life.

It looks like we could now drop support for IE<11 based on this from 
Microsoft: "Beginning January 12, 2016, only the most current version of 
Internet Explorer available for a supported operating system will receive 
technical supports and security updates. Internet Explorer 11 is the last 
version of Internet Explorer, and will continue to receive security 
updates, compatibility fixes, and technical support on Windows 7, Windows 
8.1, and Windows 10." [0]

Yes, I would say we care about mobile browsers. Django 2.0 will likely add 
responsive CSS for the admin [1].

I'm not sure what "Does Safari deserve/require special casing?" means.

[0] https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support
[1] https://github.com/django/django/pull/8610

On Wednesday, June 14, 2017 at 7:02:45 PM UTC-4, Curtis Maloney wrote:
>
> This topic seems to appear frequently over the years, but I've yet to 
> see a clear decision. 
>
> Without a clear Browser Support Policy for admin, it can be very unclear 
> what cleanups, optimisations, and improvements can be made. 
>
> Collin Anderson suggested supporting IE11+ ("as that's the latest on 
> Windows 7 and there's not much 9-10 usage"), and I'd suggest also 
> considering the general Google approach: 
>
> Basically, it's "Current and Previous version", and considering IE as 
> separate from Edge (so IE 10/11, Edge current and previous). 
>
> Does this sound fair and reasonable? 
> Do we care about mobile browsers? 
> Does Safari deserve/require special casing? 
>
> Once we can resolve this, I want to start working on revising all the 
> JS. But I won't start that until I know what dross I have to still drag 
> along. 
>
> -- 
> Curtis 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b7960cbc-0dfe-4547-b7ec-1a6dc6907f86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin browser support policy

[Philip James]

I certainly care about mobile support. Being able to use even a limited
version of Django admin on my phone would make my life significantly better.


PJJ
http://philipjohnjames.com

On Wed, Jun 14, 2017 at 4:02 PM, Curtis Maloney  wrote:

> This topic seems to appear frequently over the years, but I've yet to see
> a clear decision.
>
> Without a clear Browser Support Policy for admin, it can be very unclear
> what cleanups, optimisations, and improvements can be made.
>
> Collin Anderson suggested supporting IE11+ ("as that's the latest on
> Windows 7 and there's not much 9-10 usage"), and I'd suggest also
> considering the general Google approach:
>
> Basically, it's "Current and Previous version", and considering IE as
> separate from Edge (so IE 10/11, Edge current and previous).
>
> Does this sound fair and reasonable?
> Do we care about mobile browsers?
> Does Safari deserve/require special casing?
>
> Once we can resolve this, I want to start working on revising all the JS.
> But I won't start that until I know what dross I have to still drag along.
>
> --
> Curtis
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/c03cd097-de5c-7538-2866-a989291b9a3e%40tinbrain.net.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACXM1yFuL13wX4g%2BrGt%3DE%3D8P29W1zw5iN00dgwUrq6KGqwieLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Admin browser support policy

[Curtis Maloney]

This topic seems to appear frequently over the years, but I've yet to 
see a clear decision.


Without a clear Browser Support Policy for admin, it can be very unclear 
what cleanups, optimisations, and improvements can be made.


Collin Anderson suggested supporting IE11+ ("as that's the latest on 
Windows 7 and there's not much 9-10 usage"), and I'd suggest also 
considering the general Google approach:


Basically, it's "Current and Previous version", and considering IE as 
separate from Edge (so IE 10/11, Edge current and previous).


Does this sound fair and reasonable?
Do we care about mobile browsers?
Does Safari deserve/require special casing?

Once we can resolve this, I want to start working on revising all the 
JS. But I won't start that until I know what dross I have to still drag 
along.


--
Curtis

--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c03cd097-de5c-7538-2866-a989291b9a3e%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Follow-up to #28307: Possible app_template improvements

[mark . caglienzi]

Hello everyone,
I'm a Django user for some years now, and I find myself tweaking the app 
structure after `./manage.py startapp foo`.

I try to modularize the code and keep things separated. For example I don't 
like form classes in `views.py`, or very long `tests.py` files (and after 
also the Django code is organized like this).

Sometimes, especially when developing an app/project in more than one or 
two people, some bad habits can kick in, like:
* I'll just declare this little form class in `views.py`, because a 
separate file only for this is too much
* I need another form class, but there is also the previous form class here 
in `views.py`, no reason to create a `forms.py` file and have some form 
classes here and some there
* Now `views.py` is a big file and the effort to refactor can be too 
overwhelming now, also because we have to ship the code (for 
murphy-law-esque reasons you'll think that you HAVE to refactor in the 
worst moment. Hence you WON'T refactor.)

And the entropy tends to rise and rise.

The same can go for a single `tests.py` file.

So I forked django and did a slightly different (cleaner, I think) 
app_template, and filed a ticket in the bug tracker.

The ticket: https://code.djangoproject.com/ticket/28307
The branch on my forked project: 
https://github.com/mcagl/django/tree/mcagl/better-startapp-template

It was then that I was directed to raise the question here in the 
developer's mailing list, so I'm trying to recap the proposals here (and I 
hope to have done everything correctly):

* New files: `forms.py`, `middleware.py`, `mixins.py`, `urls.py` to 
encourage the developer (that can be a newbie) to start with a separation 
of things that will pay in the long run (and to reinforce the architecture 
of Django itself in the developer's mind)
* Refactoring `tests.py` in a `tests` module, also to encourage modularity.

I was made aware of the `startapp` option to make it use a custom template, 
but I think that a cleaner template used by default by Django can be a 
benefit to instill what I think are good habits in the Django developer 
community.

What do you think about this proposal?

Kind regards,
Mark

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0da65cd4-0496-4ec5-99b5-3d94e887dcb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Tim Graham]

To learn about some history of noConflict, I'd use this Google search: 
jquery noConflict site:code.djangoproject.com

The first two results are some tickets with discussion:
https://code.djangoproject.com/ticket/12882 - jQuery.noConflict() in admin 
breaks site specific code with jQuery
https://code.djangoproject.com/ticket/16776 - jQuery.noConflict(false) in 
jquery.init.js leaks the admin jQuery into the global namespace

Searching this mailing list for noConflict:
https://groups.google.com/d/topic/django-developers/yR2jY-8zVik/discussion 
- Using jQuery.noConflict() instead of jQuery.noConflict(true) in 
contrib.admin (2010)
https://groups.google.com/d/topic/django-developers/BENOHGuwsOQ/discussion 
- jQuery.noConflict() vs. jQuery.noConflict(true) (2011)

Maybe reading those tickets/discussions gives you some insight. I don't 
have much expertise to offer.

I'd think it'd be feasible to upgrade the admin's copy of jQuery to the 
latest release in each Django major version, but I'm not sure if doing that 
and dropping noConflict woudl be a hindrance to third-party apps that want 
to support multiple Django versions.

On Tuesday, June 6, 2017 at 5:54:16 AM UTC-4, Johannes Hoppe wrote:
>
> Hi!
>
> I didn't get your name, but this address the latest post.
>
> I think we made some good progress in the regarding this issue. The 
> inclusion of select2 is at a stage where I wouldn't want to jump to a 
> different library. Especially considering that now one acted at this ticket 
> for seven years and it took me 2 years to work on the issue and it still 
> isn't merged.
>
> That being said, the major question remaining is whether or not to disable 
> `noConflict(true)`. I don't mind, I made it work without it. But 
> maintenance wise, it's simpler to just disable it.
>
> I would love to see some feedback from the core team here. I really like 
> to get this resolved.
>
> Cheers
> -Johannes
>
> On Tuesday, June 6, 2017 at 9:36:04 AM UTC+2, is_null wrote:
>>
>> Hi all,
>>
>> In our experience, it would be worth removing noConflict, but we need 
>> Django to have a recent jQuery release, it's wasn't always the case but now 
>> it's good. I don't know who relies on that except grappeli, but they would 
>> probably be happy to get rid of their double jquery loading because that's 
>> been the source of many user issues, at least in DAL's repo.
>>
>> Another library that would be worth proposing is 
>> jquery-autocomplete-light (disclamer: I'm the author), particularely 
>> because it is built to let the server render the suggestions box, and 
>> because it's pretty light by essence (does nothing on selection but trigger 
>> an event, it's up to the developer to implement the callback). But I should 
>> do some crowdfunding or something to cover it with JS unit tests, currently 
>> it's abandoned except by most django-autocomplete-light < 3.0 users, some 
>> v3 users are using it already even thought it's not been officially 
>> released / supported, because I was maintaining it with selenium tests and 
>> that was too much of a pain of course to have no unit tests.
>>
>> If you need generic form widgets, I think we've got ok ones in 
>> django-autocomplete-light v3. Again what's missing for developer experience 
>> is just the ability to override the default form, without having to 
>> subclass the world just to pass it: when you need an autocomplete on a 
>> field, you most likely need it everywhere, ie. because the select would 
>> load too many options to be usable.
>>
>> We'd be very happy to see noConflict removed, and try to all rely on the 
>> latest jQuery, rather than all try to load our own and deal with different 
>> variables names for jQuery. Perhaps I should try this in a fork, even if 
>> that means DAL will require extra steps for users not on that specific 
>> Django fork, at least we'd figure out if removing noConflict had unseen 
>> drawbacks.
>>
>> Best
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f92d7c25-8084-48ca-b671-7df30d19ef36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider making asgi_rabbitmq an official Django project.

[Tim Graham]

>From my perspective, there's been little visibility into how things are 
going with the other channels related official projects. Who are the other 
maintainers there? I would present this question to those people (hopefully 
there are some others by now?) rather than to the Django maintainers which 
is who I think of when you say "Django core" (a term we're trying to 
replace with "Technical team" and "Technical advisory team" [0]). 
Organizationally, I think it could be nice if channels has its own 
technical team rather than giving the impression that the Django 
maintainers are also stewarding all other official projects.

[0] https://www.djangoproject.com/foundation/teams/

On Tuesday, June 13, 2017 at 9:22:30 PM UTC-4, Andrew Godwin wrote:
>
> Hi Artem,
>
> Thanks for adding the comments - it does look better. The thing I would 
> like to have is more feedback from Django core about this; I've not heard 
> anyone's opinion but mine, and I am not entirely sure if we should do this 
> (I am also not entirely sure asgi_ipc should be a Django project some days).
>
> Andrew
>
> On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev  > wrote:
>
>> Hi Andrew,
>>
>> I'm very glad to hear it's considered useful. If you look at recent 
>> master you can see that I've added documentation and comments to the code.
>>
>> Exact commit 
>> https://github.com/proofit404/asgi_rabbitmq/commit/9add0b8fec10ff93f8a813838f4f8ad87fde7e1f
>>
>> Also, I found the second maintainer for the project, Andrii Soldatenko.  
>> He is in the mail carbon copy.
>>
>> Any insights what to do next?
>>
>> Regards, Artem.
>>
>> On Sunday, June 11, 2017 at 4:08:20 AM UTC+3, Andrew Godwin wrote:
>>>
>>> Hi Artem,
>>>
>>> I know we've discussed this privately but I want to put some things on 
>>> the public list (and get at least one reply).
>>>
>>> My view is that it would be useful to have it maintained, but I do not 
>>> personally have the spare time to help maintain it, so it would need at 
>>> least one other person to help you maintain it before we could accept it 
>>> (they would not have to be existing core, but would need some history of 
>>> open-source maintenance)
>>>
>>> The other thing would be to see the existing code have more comments and 
>>> documentation; currently it has very few comments, in particular.
>>>
>>> Andrew
>>>
>>> On Thu, Jun 8, 2017 at 9:39 PM, Artem Malyshev  
>>> wrote:
>>>
 Hi everyone,

 asgi_rabbitmq is Channels layer on top of RabbitMQ.  It was originally 
 developed as part of Mozilla funding program.

 I've complete few major milestones after this.  Now it's used in few 
 production systems.  It implements the ASGI specification exactly and 
 performs well.

 I want to make asgi_rabbitmq an official Django project.

 Reasons why I want this happens:

 - It will be widely used.  Major changes in the Channels and ASGI will 
 take this library into account.

 We need:

 - Discuss if it's interesting at all for Django project.  Find at least 
 one more person who understands library code.  Documentation has a 
 comprehensive chapter about internal design and implementation.

 Conditions under which I prefer it happens:

 - I want to keep commit access for this repository for future 
 development and fixes.  - I'll keep it up to date with coming channels 
 releases.  - I'll do initial preparation steps for code transfer like code 
 clean up if necessary.  But I need receive some comments after code review.

 Project repository: https://github.com/proofit404/asgi_rabbitmq

 Regards, Artem.

 -- 
 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 post to this group, send email to django-d...@googlegroups.com.
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/69328d61-68fd-47b8-8f1b-a4f0cc85f7cf%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> 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 post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this 

Re: Default to BigAutoField

[Melvyn Sopacua]

On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote:
> However, it should also be noted that those same larger applications
> are the ones that are likely to run into this problem eventually, so
> perhaps forcing the migration is the best path moving forward.


Existing models are the problem. Then again the database knows the truth. So 
with a little inspection during apps.get_models we might be able to do the 
right 
thing and even allow migrating in steps.

Apps is also the place to mark an app as migrated.

In fact - couldn't an AppConfig grow a method "get_autoid_type()" and inject 
the right one?

You asked fr thoughts, so there's my 2c stream.
-- 
Melvyn Sopacua

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8118805.cf4lglgPtt%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Tom Christie]

> I note that your examples do not include "receiving messages from a 
WebSocket and sending replies" - I would love to see how you propose to 
tackle this given your current API, and I think it's the missing piece of 
what I understand.

I've just added an `echo` WebSocket example.

I've also now added support for broadcast, currently implemented using 
Redis Pub/Sub.
There's a full example for a chat server that can be properly distributed. 
(*)

Aside: Right now that *happens* to be implemented as middleware, but 
there's no reason it couldn't equally well be integrated at the server 
level, so not a detail to get sidetracked by. More important is how the 
application interface for it looks.

(*) Yes, you'd have sticky WebSockets.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2da48b17-b47f-42e3-b1bb-4a0e5a9b5709%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.