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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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 ...
>
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
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
>
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
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
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
>
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
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)
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
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
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
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
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
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
31 matches
Mail list logo