Re: Django Integration

2016-05-04 Thread Mark Lavin
Thank you Russ. I'll reconsider expressing my full thoughts on Channels more likely in another thread. For now I do think it's worth addressing this issue of benchmarks/performance which keeps being brought up. The argument is that since this is optional we don't need to see the benchmarks

Re: re-thinking middleware

2016-05-04 Thread charettes
Hi Tim, I think we should favor displaying a message in accordance with the setting the user is using as it will make the transition less confusing. In the case of the documented check message I think using the form "MIDDLEWARE/MIDDLEWARE_CLASSES" would make it easier to read then mentioning

Re: Django Integration

2016-05-04 Thread Russell Keith-Magee
Hi Mark, On Thu, May 5, 2016 at 8:41 AM, Mark Lavin wrote: > 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

Re: Django Integration

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 6:12 PM, Tim Graham wrote: > The future is hard to predict, but I'll add that I'm a tad nervous about > this as well. > > I'm completely inexperienced with channels at this time. Who else has a > good grasp of the code right now and could help fix

Re: Django Integration

2016-05-04 Thread Tim Graham
The future is hard to predict, but I'll add that I'm a tad nervous about this as well. I'm completely inexperienced with channels at this time. Who else has a good grasp of the code right now and could help fix release blocking bugs if Andrew isn't available? Are we playing for any or all bug

Re: Django Integration

2016-05-04 Thread Mark Lavin
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: re-thinking middleware

2016-05-04 Thread Tim Graham
I've been working on this and wanted to raise a couple points for discussion. How should we treat error messages in place like system checks where we have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much

failure to load fixtures during unit tests

2016-05-04 Thread Rich Rauenzahn
I'm in the middle of trying to track down a problem with loading fixtures during unit tests -- I'm hesitant to call it a bug in Django 1.7, but the inconsistent behavior is really stumping me. Essentially I've made a fixture via manage dumpdata --indent=3 -e sessions -e admin -e

Re: Good idea to transition from MS Access to local webapp built on Django?

2016-05-04 Thread Olivier Dalang
Hi, We use it here for a similar use case (small NGO's project management database) and are very happy. It's almost exclusively based on django-admin to keep everything as modular and easy to maintain as possible, which means our forms can't be too complex and do reflect the database schema (1

Re: Django Integration

2016-05-04 Thread Jacob Kaplan-Moss
On Wed, May 4, 2016 at 2:45 PM, Marc Tamlyn wrote: > Major features merged into Django have generally never been as "perfect" > as the standards required for smaller patches. There's a recognisation of > the need for ongoing work, probably over the course of multiple

Re: Django Integration

2016-05-04 Thread Marc Tamlyn
Major features merged into Django have generally never been as "perfect" as the standards required for smaller patches. There's a recognisation of the need for ongoing work, probably over the course of multiple versions, in order to perfect any major new feature. The effort involved in getting a

Call for Channels work

2016-05-04 Thread Andrew Godwin
Hi everyone, We finally have everything in place to pay people from the MOSS funds given to us by Mozilla for Channels (and more importantly we now have the money itself), so now I'd like to open the call for help. We have a list of tasks that need doing in Channels, and the money to pay people

Re: Django Integration

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 12:28 PM, Mark Lavin wrote: > I can (and do) appreciate the effort that's gone into this work while > still feeling as though it isn't ready to be merged with Django. To be > honest given that this PR contains almost no changes to Django itself and >

Re: Django Integration

2016-05-04 Thread Mark Lavin
I can (and do) appreciate the effort that's gone into this work while still feeling as though it isn't ready to be merged with Django. To be honest given that this PR contains almost no changes to Django itself and only adds new code, I don't understand why it can't live outside of Django while

Re: Django Integration

2016-05-04 Thread Mark Lavin
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

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 11:52 AM, Mark Lavin wrote: > > > Given that there is no guarantee of message delivery, I don't think this > is suitable or recommended for using for background tasks. I don't think > the Django docs should encourage that usage. At least without a

Re: Django Integration

2016-05-04 Thread Mark Lavin
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 > wrote: > >> As noted in the PR there is at least one new setting, >> CHANNEL_SESSION_ENGINE, which is lacking documentation. >> > > That's been added

Re: Django Integration

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 10:06 AM, Markus Holtermann wrote: > What about having asgiref and daphne as optional dependencies instead of > hard once and raising a proper exception "please install ..." when the > import fails? > > ``` > try: >from asgiref import ... >

Re: Django Integration

2016-05-04 Thread Markus Holtermann
What about having asgiref and daphne as optional dependencies instead of hard once and raising a proper exception "please install ..." when the import fails? ``` try: from asgiref import ... except ImportError: raise ImportError( "Please ensure you installed asgiref to use this

Re: Django Integration

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 8:26 AM, Mark Lavin wrote: > As noted in the PR there is at least one new setting, > CHANNEL_SESSION_ENGINE, which is lacking documentation. > That's been added now. > The notes on deployment for "Running ASGI under WSGI" don't give any >

Re: Django Integration

2016-05-04 Thread Mark Lavin
As noted in the PR there is at least one new setting, CHANNEL_SESSION_ENGINE, which is lacking documentation. The notes on deployment for "Running ASGI under WSGI" don't give any motivation why you would want to do this given that it doesn't support websockets in this case. Is there any

Re: upgrade from 1.4 to 1.8

2016-05-04 Thread Tim Graham
I don't recall any similar reports. Anyway, "is it a bug?" questions go to django-users. You'll need to include steps to reproduce the issue in order to get help. On Wednesday, May 4, 2016 at 7:29:52 AM UTC-4, Samarjeet Singh wrote: > > the problem is on the flush function of django 1.8 and

Re: Django Integration

2016-05-04 Thread Andrew Godwin
On Wed, May 4, 2016 at 6:15 AM, Mark Lavin wrote: > 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 >

Re: Django Integration

2016-05-04 Thread Mark Lavin
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: Post-Mortem of the djangoproject.com outage earlier today.

2016-05-04 Thread Jacob Kaplan-Moss
Thanks for the info, and for the quick fix! Jacob On Wed, May 4, 2016 at 3:48 AM, Florian Apolloner wrote: > Hi, > > earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from > our ansible repository to dp.com. This branch included our old (now > expired)

Re: upgrade from 1.4 to 1.8

2016-05-04 Thread Samarjeet Singh
i think this is a development issue because of request.session.flush if i logout all the session detail is deleted and not modified because of which next time when we login there is a session conflict so i dont know if it ths problem is with everyone or only i am facing it . Please help!! On

Re: upgrade from 1.4 to 1.8

2016-05-04 Thread Samarjeet Singh
the problem is on the flush function of django 1.8 and because of which the session is deleted instead of modifying and then a new session is created at logout and which gets conflicted with the new user session so that is why i am not able to log in .so is this problem with me only or others

Re: Django website ssl-certificate expired

2016-05-04 Thread Markus Holtermann
A post-mortem is at https://groups.google.com/forum/#!topic/django-developers/7qzh2n3ZDRc Cheers, /Markus On Wednesday, May 4, 2016 at 11:51:08 AM UTC+2, Marc Tamlyn wrote: > > We are aware of the issue and are working on it. > > Thanks, > Marc > > On 4 May 2016 at 10:30, Wim Feijen

Post-Mortem of the djangoproject.com outage earlier today.

2016-05-04 Thread Florian Apolloner
Hi, earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from our ansible repository to dp.com. This branch included our old (now expired) gandi SSL certificate. Once I realized what I did (which took a few minutes since I was preparing to push a commit) I switched to the proper

Re: Django website ssl-certificate expired

2016-05-04 Thread Marc Tamlyn
We are aware of the issue and are working on it. Thanks, Marc On 4 May 2016 at 10:30, Wim Feijen wrote: > Hi guys, > > Apologies if I am posting in the wrong group, but the certificate of > djangoproject.com expired today (4 May). > > Wim > > -- > You received this message

Django website ssl-certificate expired

2016-05-04 Thread Wim Feijen
Hi guys, Apologies if I am posting in the wrong group, but the certificate of djangoproject.com expired today (4 May). Wim -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group