Hello,
With all the talk of DEPs flying around I thought I'd finally take a look
at one in detail.
I wanted to make a suggestion about it and realized that there wasn't
really a good place to do so. The issue was too minor for a mailing list
discussion, and there was no open pull request to co
Sorry for the late entry to the discussion, but I was looking over the
code and wondered about something.
In projects where I've used my django-sniplates for form rendering, it's
been helpful that I can have several different form widget sets within
the one project -- for instance, for side-by
+1. I like the simpler fallback solution Carl has suggested also.
Preston
--
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
On Tue, May 10, 2016 at 1:58 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 10 May 2016, at 19:18, Carl Meyer wrote:
>
> > I would say that a DEP is generally a good idea if the people working on
> > the feature feel that it would be helpful to them to organize and record
Hi everyone,
Following my decision to move Channels away from a 1.10 merge and towards
an existence as a separate app for a bit while it matures, I would like to
write up a process DEP for how we achieve this - specifically, what it
takes to be adopted as a non-core app, what that means for the Dj
On 05/07/2016 08:27 AM, Tim Graham wrote:
> Thanks, I have what I hope is a minimally mergable patch here:
> https://github.com/django/django/pull/6501
Thanks Tim (and Florian for all the previous work on this patch). I've
updated the DEP with a couple minor changes to reflect the latest
learnings
On 10 May 2016, at 19:18, Carl Meyer wrote:
> I would say that a DEP is generally a good idea if the people working on
> the feature feel that it would be helpful to them to organize and record
> the various design decisions
DEPs have the additional advantage or drawback, depending on your persp
Hi Tim,
On 05/10/2016 07:10 AM, Tim Graham wrote:
> About the fallback engines, the main use case I have in mind (as Claude
> alluded to) is if you want to use django.forms "standalone" without the
> rest of Django. In that case, it seems like it would be nice not to
> require someone to configure
On Tue, May 10, 2016 at 10:25 AM, Carl Meyer wrote:
> On 05/10/2016 10:39 AM, Andrew Godwin wrote:
> > - Being almost purely an addition to Django, even though it technically
> > inserts a new layer, makes it more well-suited to live externally than
> > many other features. While the external pa
Seems sensible. In particular having the documentation available as part of the
regular Django docs would mean there's very little difference to the end user,
but without us having to get everything merged into the core codebase. Is the
docs element something we can reach a consensus on, or are
On 05/10/2016 10:39 AM, Andrew Godwin wrote:
> - Being almost purely an addition to Django, even though it technically
> inserts a new layer, makes it more well-suited to live externally than
> many other features. While the external package will have to
> monkey-patch a few things, it'll be relat
Hi Anssi,
Thanks for the clarification, that all makes sense. A few comments below:
On 05/10/2016 12:00 AM, Anssi Kääriäinen wrote:
> It's not so much the DEPs that have been written (though the channels
> DEP is going to be post-design instead of supporting the design). It's
> more about those f
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 wro
Thank you, Andrew, for your hard work. Channels is an exciting new feature, and
I'm glad that you're bringing it together. You're doing an excellent job.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
Hi everyone,
I'm going to withdraw the Channels patch for consideration for 1.10;
there's a lot more concern and uncertainty around it than I had
anticipated, given the reaction up until this point, and it's clear I have
some more work to do at convincing the community and proving the design.
Ins
> The notion that I would now have to use a data store to run my app at all
didn't feel right
Fortunately, you don't need to. From the docs in the pull request... "It's
an optional part of Django; you don't need to interact with it if you're
just writing a normal website, but if you want the fe
Correction:
*JKM starred (not started) - stupid, stupid iPhone.
--
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-de
To hopefully add to this conversation:
I'll start by saying I've enjoyed the contributions by Andrew over the years
and believe he is a most excellent developer.
A couple months ago, around the same time that JKM started Andrew's repo (which
is what got my attention) I decided to give Channels
About the fallback engines, the main use case I have in mind (as Claude
alluded to) is if you want to use django.forms "standalone" without the
rest of Django. In that case, it seems like it would be nice not to require
someone to configure settings.TEMPLATES. Here's an alternate proposal:
Crea
My preference would be to shift the alpha deadline *without* yet making a
firm decision on if channels hits 1.10 or not. That would take a little
pressure off, and not force anyone into making a decision prematurely.
Moving the window back (say 3 weeks?) and allowing a little more time for
the
20 matches
Mail list logo
