Re: Withdrawing Channels from 1.10

Yes thank you Andrew for your continued work to move this conversation forward. I hope that Channels can continue to grow as an external package under the Django umbrella and bring on more contributors and improvements. Best, Mark On Tuesday, May 10, 2016 at 12:44:21 PM UTC-4, Ryan Hiebert

Re: My Take on Django Channels

, Mark, for starting this discussion. I, too, found myself simply > accepting that channels was the right way to go, despite having the same > questions you do. I realize this shouldn't be, so I've chimed in on some of > your comments. > > > On May 5, 2016, at 2:34 PM, Mark Lavin <ma

Re: My Take on Django Channels

at 8:52:17 PM UTC-4, Andrew Godwin wrote: > > > > On Thu, May 5, 2016 at 5:13 PM, Mark Lavin <markd...@gmail.com > > wrote: > >> Yes I agree with the value of a standardized way of communicating between >> these processes and I listed that as a highlight of Cha

Re: My Take on Django Channels

wrote: > > > > On Thu, May 5, 2016 at 2:19 PM, Mark Lavin <markd...@gmail.com > > wrote: > >> Thank you for your comments and I have some brief replies. >> >> >> If I'm understanding it correctly, groups are an emulated broadcast. I'm >>

Re: My Take on Django Channels

Thank you for your comments and I have some brief replies. On Thursday, May 5, 2016 at 4:20:06 PM UTC-4, Andrew Godwin wrote: > > > > On Thu, May 5, 2016 at 12:34 PM, Mark Lavin <markd...@gmail.com > > wrote: > > The main gains are (in my opinion): > - The same

Re: My Take on Django Channels

On Thursday, May 5, 2016 at 4:20:06 PM UTC-4, Andrew Godwin wrote: > > > > On Thu, May 5, 2016 at 12:34 PM, Mark Lavin <markd...@gmail.com > > wrote: > >> After somewhat hijacking another thread >> https://groups.google.com/d/msg/django-developers/t_zuh9ucSP4/eJ

My Take on Django Channels

process and I will admit that has jaded many of my interactions with the core team. Building consensus is hard and I’m posting this to help work towards the goal of community consensus. Thanks for taking the time to read this all the way through and I welcome any feedback. Best, Mark Lavin

Re: Django Integration

erformance or say that isn't a requirement to even measure, regardless of outcome, before its inclusion? - Mark On Wednesday, May 4, 2016 at 10:00:15 PM UTC-4, Russell Keith-Magee wrote: > > Hi Mark, > > On Thu, May 5, 2016 at 8:41 AM, Mark Lavin <markd...@gmail.com > > wrote:

Re: Django Integration

Major features have never been perfect, no, but they have in the past typically gone through two paths to prove out their design/API/usefulness. One is as an established and mature third-party app such as messages, staticfiles, and django-secure. More recently the other has been through the

Re: Django Integration

it continues to mature. Best, Mark On Wednesday, May 4, 2016 at 3:18:03 PM UTC-4, Andrew Godwin wrote: > > > > On Wed, May 4, 2016 at 11:52 AM, Mark Lavin <markd...@gmail.com > > wrote: > >> >> >> Given that there is no guarantee of message de

Re: Django Integration

I like Markus' suggestion and I think that's in line with how Django handles other optional dependencies such as the db bindings (psycopg2, MySQLdb, etc). Those raise an ImproperlyConfigured exception when there is an import error. The memcache cache backend on the other hand raises an import

Re: Django Integration

On Wednesday, May 4, 2016 at 12:39:02 PM UTC-4, Andrew Godwin wrote: > > > > On Wed, May 4, 2016 at 8:26 AM, Mark Lavin <markd...@gmail.com > > wrote: > >> As noted in the PR there is at least one new setting, >> CHANNEL_SESSION_ENGINE, which is lacking doc

Re: Django Integration

en't required to run. If these we're in the install_requires then I would withdraw the objections about them with regard to this change in Django. -Mark On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote: > > On Wed, May 4, 2016 at 6:15 AM, Mark Lavin <markd...@gmail.com

Re: Django Integration

I had assumed this was still a work in progress because there are missing tests and some documentation. The build is passing but the unittest coverage for the new modules seems low or at least not up to the standards I expect for Django contributions. The same for the daphne and asgiref

Re: Channels integration plan, first draft

I'm not trying to be needlessly critical of your work. On Fri, Dec 18, 2015 at 10:07 AM, Andrew Godwin <and...@aeracode.org> wrote: > > > On Fri, Dec 18, 2015 at 2:00 PM, Mark Lavin <markdla...@gmail.com> wrote: > >> Anssi criticisms are fair and I feel that some of the

Re: Channels integration plan, first draft

Anssi criticisms are fair and I feel that some of these responses are glossing over the details. You've claimed this is the same or equivalent to a forked worker model but it isn't because there is no process management/link between the interface and worker and because you've chosen to make this

Re: Channels integration plan, first draft

I have concerns about "built-in feature" means for existing applications (and future applications really). Under "Preserving Simplicty" you note that you should be able to run Django as simply as you do now. Is there a consideration to run "classic" WSGI applications without channels? This

Re: Django Content Negotiation implement

Hi, Tom has done a great job describing why this has stalled recently. I plan to pick back up on this now that the book has been released. I agree that defining the public API is the best first step and the current DEP is not sufficient in this regard. Before making any internal changes we

Re: Migrations and Reusable Apps

Support of south_migrations directory in South goes a long way to addressing this problem from my perspective so that's very good news to me. On Tuesday, June 17, 2014 1:34:02 PM UTC-4, Trey Hunner wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/17/2014 10:05 AM, Andrew

Re: Migrations and Reusable Apps

the app starts shipping its own migrations > will go. > > On Tuesday, June 17, 2014 9:18:57 AM UTC-4, Mark Lavin wrote: >> >> Hello, >> >> I noticed some changes over the past few days to the migrations and I was >> concerned about how this could im

Migrations and Reusable Apps

Hello, I noticed some changes over the past few days to the migrations and I was concerned about how this could impact reusable applications planning to support 1.7. In particular there is a note in https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies Be aware, however, that

Re: DEPs: Django Enhancement Proposals

I'll be the first one to bite and submit one https://github.com/django/deps/pull/1 It needs a lot of work as noted in the PR but I'm happy to be a guinea pig for the process. Best, Mark On Monday, April 14, 2014 8:41:07 PM UTC-4, Russell Keith-Magee wrote: > > On Tue, Apr 15, 2014 at 2:17 AM,

Re: Deprecating Widget Media class

In my experience using the Media class is really only helpful in one place: the admin. If you have a third-party widget which requires CSS or JS is a pain to include it without the use of Media. Users want to just include the widget in the form class and have it "just work". A majority of the

Re: Migrations in Django 1.7 make unit testing models harder

I don't see any meaningful notes about apps being required to ship migrations beginning with 1.9. I do see deprecation notes about the syncdb signals changing and the syncdb command itself is clearly deprecated. This legacy behavior is handled by sync_apps in the migrate command but there

Re: Migrations in Django 1.7 make unit testing models harder

Andrew, Can you clarify exactly what is deprecated in this work-around? I don't see anything in the deprecation timeline to remove MIGRATION_MODULES nor any pending deprecations related to its usage. It seems like could probably be replaced by something that uses the app-loading/app-configs

Re: #20824 - Email-based auth contrib module; some help required

Welcome to the pain that third party app maintainers have already been dealing with for the past year. I ran into this problem as well when I added custom user support to one of the apps I maintain. As you noted you can't simply change the AUTH_USER_MODEL setting because once the test DB is

Re: DisallowedHost causes 500 errors.

This was already changed in https://code.djangoproject.com/ticket/19866 which is part of 1.6. It's noted under the minor features https://docs.djangoproject.com/en/1.6/releases/1.6/#minor-features SuspiciousOperation has been differentiated into a number of subclasses, and each will log to a

Re: Migrations and System Checks

ght place for now. > > If we could get some context for the checks - things like "this check is > only for interactive runserver sessions" - then it would fit there. Perhaps > we do, I've not looked into checks too much. > > Andrew > > > On Wed, Feb 12, 2014 at 10:28

Migrations and System Checks

Last weekend I set out to fix https://code.djangoproject.com/ticket/21856 which was a 1.7 release blocker and holding up additional 1.7 testing for a project I'm currently working on. Upon diving in I saw that the checks for un-applied migrations were tied to the runserver command. I thought to

Re: e-mail changed to email in email validator

This was changed as part of https://code.djangoproject.com/ticket/17899 Best, Mark On Wednesday, December 19, 2012 4:23:24 PM UTC-5, Skylar Saveland wrote: > > I checked out 1.5 branch today and found a change that I can't find the > debate/announcement for: e-mail to email in > >

Re: Trigger an event on add another

When I was working on a similar issue for django-selectable I created an issue to address this problem with a simple proof of concept patch https://code.djangoproject.com/ticket/15760. However I never followed through with the ticket to try to get something like this added. In the meantime

Re: #3011 - Custom User Models -- Call for final review

I've been thinking about external app compatibility as well and it seems like: from django.conf import settings AUTH_USER_MODEL = getattr(settings, 'AUTH_USER_MODEL', 'auth.User') class SomeModel(models.Model): author = models.ForeignKey(AUTH_USER_MODEL) is the easiest solution to

Re: Backporting some Python 3 support features to 1.4.x?

Hi, I am one such author and I wanted to share my experience. I have ported my code and test suites for 3 applications to run on Django 1.3-1.5dev and Python 2.6, 2.7 and 3.2 (1.5dev only). Those are https://github.com/mlavin/django-responsive, https://github.com/mlavin/django-ad-code and

Re: Don't assume that missing fields from POST data are equal to an empty string value.

I think Ian demonstrated exactly why this should not go in and that is not all forms are ModelForms. Imagine writing a REST API which allows for an optional format parameter for GET requests which is validated by a Django form. With the inclusion of this proposal all clients would be forced to

Re: Don't assume that missing fields from POST data are equal to an empty string value.

> If optional fields are > left off the HTML form deliberately, without change the Form class or > the view code, this is exactly when data loss will currently occur. > I think you are confusing optional as in "may not be specified by the > user" with optional as in "may not be processed by the