GitHub Issues for DEP repository?

[Kevin Christopher Henry]

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 comment on. My first 
instinct was to file a GitHub issue (and DEP 1 says "you can submit 
corrections as GitHub issues") but it seems that Issues has been disabled 
for this repository. Was that just an oversight?

More broadly, I think that DEP 1 makes this subject too complicated: "How 
you report a bug, or submit a DEP update depends on several factors, such 
as the maturity of the DEP, the preferences of the DEP author, and the 
nature of your comments. For the early draft stages of the DEP, it's 
probably best to send your comments and changes directly to the DEP author. 
For more mature, or finished DEPs you can submit corrections as GitHub 
issues or pull requests against the DEP repository. When in doubt about 
where to send your changes, please check first with the DEP author and/or a 
core developer."

It adds some friction to the process to ask someone to contact the DEP 
author directly to ask them whether or not they should contact them 
directly with their comments. I think it would be more straightforward to 
just use the usual complement of open-source tools that we all know and 
love: the developers mailing list, pull requests, and an issue tracker.

I would have filed this as an issue, but... :-)

-- 
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/3cc307c1-c329-4ffb-9848-ac0470731207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Curtis Maloney]

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-side labels, or top-labels, 
etc.


From what I can see so far of the code/docs, there's no way to override 
which set of form widgets get used on a per-form basis... let alone 
per-field.


Is this correct?

The only possible avenue I see is a custom renderer class that somehow 
mangles the widget template paths...


--
Curtis

On 11/05/16 13:21, Preston Timmons wrote:

+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 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/a5f5ad63-71f0-4ba5-bd21-028d79b0a3b4%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-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/5732A7B7.7090403%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Preston Timmons]

+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 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/a5f5ad63-71f0-4ba5-bd21-028d79b0a3b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs (was: Making Django more PaaS-friendly)

[Andrew Godwin]

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
> > the various design decisions
>
> DEPs have the additional advantage or drawback, depending on your
> perspective,
> of raising the bar for arguing about the design. The first step is to read
> 10
> to 20 pages, and perhaps a bunch of other sources they reference.
>
> Compared to the traditional process, which simply consists in ranting on
> this
> mailing-list based on partial data and approximate assumptions, DEPs take
> all
> the fun away ;-)
>
> (More seriously: discussions are rarely very bad here, however I believe
> that
> a DEP makes them much more efficient once a certain amount of complexity is
> reached, because the DEP provides a consolidated vision of the discussion.)
>

I'd like to agree with this point strongly - having a centralised place
that outlines the entire approach and all the discussion around it seems
invaluable for larger features, and would have been Nice To Have given
recent events.

Andrew

-- 
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/CAFwN1uouyxp2tMn1qffyQk%3Dr_mP99SUmtGiMQ7HN-dfvGNxHuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Process DEP for "official" non-core projects

[Andrew Godwin]

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 Django
organisation, and what its goals should be.

Given recent events, I feel having a process that's agreed upon and
specified is a good move for this, especially if we do it with something
else again in future.

My rough outline is as follows:

 - A non-core project can be moved under the governance of the Django
project if it is deemed an important feature that's in our interests to
maintain and grow

 - We should be relatively convinced that it represents the best
implementation of the feature that there is, that it is matured and has a
stable release, and that there aren't competing implementations at a
similar level

 - The decision-making structure is similar to that of a DEP, in that there
must be a core "shepherd" who is the go-to person for it and makes sure it
crosses the basic test, and a technical board vote on inclusion.

 - A project under Django governance will fall under the Django umbrella
for security-related reports and fixes, and will maintain the Django
security policy on the current major release only.

 - Release schedule will not be fixed to Django's and no LTS pattern will
be forced on it, and a limited backwards-compatibility policy of only "at
least one major version" will be maintained.

I think it's worth working out how the whole thing is going to run if we're
going to do it properly, and the DEP system seems like the best place for
something like this. If we do go down the path of starting to split out
Django into more packages, as well, it could provide a useful base for that
to structure around (though we'd want to beef up security/backwards-compat
timelines).

It's also probably sensible that whatever we come up with covers
localflavor, as well, since that's sort of in this state already.

Andrew

-- 
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/CAFwN1ur%3D-RAxA72vTxT2bq5-QVDLcdnOiXK_HnvyjwZHpi_izw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Carl Meyer]

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 from the implementation; you can see the latest changes at
https://github.com/django/deps/compare/763530e1a9...master

I reviewed this thread and I think the response was pretty much
positive; I didn't see any outstanding unaddressed concerns. If you have
any, please let me know! I plan to ask the technical board to approve
DEP 5 shortly.

> As noted on the PR, there a more things that should be before the 1.10
> feature freeze but I'm hoping I can ticket them out and get some help
> from the community after merging this first step so that I can continue
> spending most of my time reviewing patches.

I can't help with a new graphic for the docs, but I will take care of
the decorator_from_middleware update tomorrow.

I'm not entirely sure that a graphic is still needed with the new
system; its behavior is simpler than the old. But if a motivated and
appropriately skilled party provides a useful graphic, that'd be great
of course!

Carl

> On Friday, May 6, 2016 at 7:59:38 PM UTC-4, Carl Meyer wrote:
> 
> I agree with Simon on both counts. We do usually continue to test
> deprecated code paths until they are removed, but I also think the
> duplication in cases of tests overriding MIDDLEWARE_CLASSES might
> not be
> necessary in _all_ cases; I think some discretion could be used
> depending on to what extent the middleware is incidental to the
> tests vs
> the direct subject of the test. But it might be simpler to just do them
> all than to make that determination.
> 
> Carl
> 
> On 05/04/2016 08:57 PM, charettes wrote:
> > 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 the two possible variants. We already alter the document
> > messages anyway to account for their dynamic nature.
> >
> > In the case of the tests I believe both code path should continue
> to be
> > tested. From the top of my head I can't think of an alternative to
> > subclasses using @override_settings. I suggest we make the *legacy*
> > tests class extend the MIDDLEWARE using test class and not the
> other way
> > around as it will make the MIDDLEWARE_CLASSES code removal clearer.
> >
> > Simon
> >
> > Le mercredi 4 mai 2016 19:59:05 UTC-4, Tim Graham a écrit :
> >
> > 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 effort but should we make the error message
> "smart" and
> > display the version of the setting that the user is using?
> > Alternatively, we could always reference MIDDLEWARE (the
> > non-deprecated version) or use some variation like
> > "MIDDLEWARE(_CLASSES)" or "MIDDLEWARE/MIDDLEWARE_CLASSES"
> until the
> > deprecation period ends.
> >
> > Another point for discussion is whether we need to duplicate a
> lot
> > of tests so we test that the middleware continue to work with
> both
> > the old-style MIDDLEWARE_CLASSES and the new style MIDDLEWARE
> > response handling. I guess a subclass of anything that uses
> > @override_settings(MIDDLEWARE=...) that uses
> > @override_settings(MIDDLEWARE_CLASSES=...) might work. Just
> putting
> > it out there in case anyone has a better idea.
> >
> > On Monday, January 18, 2016 at 9:20:03 PM UTC-5, Carl Meyer
> wrote:
> >
> > I've updated DEP 5 with a new round of clarifications and
> tweaks
> > based on the most recent feedback:
> > https://github.com/django/deps/compare/62b0...master
> 
> >  >
> >
> > Carl
> >
> > --
> > 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 

Re: DEPs (was: Making Django more PaaS-friendly)

[Aymeric Augustin]

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 perspective,
of raising the bar for arguing about the design. The first step is to read 10
to 20 pages, and perhaps a bunch of other sources they reference.

Compared to the traditional process, which simply consists in ranting on this
mailing-list based on partial data and approximate assumptions, DEPs take all
the fun away ;-)

(More seriously: discussions are rarely very bad here, however I believe that
a DEP makes them much more efficient once a certain amount of complexity is
reached, because the DEP provides a consolidated vision of the discussion.)

-- 
Aymeric.

-- 
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/5DB56C87-8DE1-450F-8F97-60E909D02F65%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Carl Meyer]

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 settings.TEMPLATES. Here's an alternate
> proposal:
> 
> Creating a "django.forms.renderers.templates.DefaultTemplateRenderer"
> (exact name to be discussed) which uses the fallback engines and ignores
> settings.TEMPLATES. This could be the default renderer for the
> FORM_RENDERER setting, for backwards-compatibility and to allow
> django.forms standalone usage by default. For more advanced uses, set
> the setting: FORM_RENDERER =
> 'django.forms.renderers.templates.TemplateRenderer' (which uses
> django.template.loader.get_template and doesn't have any fallback engines).

Yeah, I considered this (my first version of my commit actually had two
different renderer classes like this). My concern is that I think this
proposal has the default backwards for what will actually be typical
usage. In my experience of using templated widgets for the last several
years (via django-floppyforms), the biggest value is the ability to
override specific widget templates with your own templates. So I think
overriding templates (within a normal Django project with TEMPLATES
configured) is the "basic usage" and standalone use of the forms library
is an "advanced use," not the other way around.

The proposed "DefaultTemplateRenderer" doesn't allow any template
overriding at all, because it can _only_ load the built-in templates. I
think in the long run it would be a mistake to have the default
FORM_RENDERER setting be a renderer that doesn't allow easily overriding
templates, and I don't think that we should allow the transition
concerns to override reaching the right long-term solution after a
transition path.

Carl

-- 
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/573226C2.9050807%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Withdrawing Channels from 1.10

[Andrew Godwin]

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 package will have to
> > monkey-patch a few things, it'll be relatively minor.
>
> Are there small changes that could be made in Django 1.10 that would
> reduce the monkeypatching burden? In the channels repo it seems the only
> remaining monkeypatch in hacks.py is for staticfiles' runserver; are
> there other monkeypatches I'm missing?
>
> The staticfiles case is a known problem with management command
> overriding, and I don't have a good solution. I guess it's a choice
> between monkeypatching vs having to document a required ordering of
> staticfiles vs channels in INSTALLED_APPS.
>

Yes, that's the main one, and I'll probably leave that in place. There are
a couple of fixes I'd like to get in to the sessions objects so it's easier
to bring in predefined keys, and untangle BaseHandler a bit, but they're
not super important so I'll get them in before the beta if I can; if not,
the current approach works well enough.

Andrew

-- 
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/CAFwN1uqc%3D6h2EHVwiEvr7NZn9NZRKGVx7Nyr_axLbteyQyW%2BCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Withdrawing Channels from 1.10

[Tom Christie]

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 there any objections 
to that approach?

-- 
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/babd844f-492a-4e72-8e56-fd1604b02d5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Withdrawing Channels from 1.10

[Carl Meyer]

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 relatively minor.

Are there small changes that could be made in Django 1.10 that would
reduce the monkeypatching burden? In the channels repo it seems the only
remaining monkeypatch in hacks.py is for staticfiles' runserver; are
there other monkeypatches I'm missing?

The staticfiles case is a known problem with management command
overriding, and I don't have a good solution. I guess it's a choice
between monkeypatching vs having to document a required ordering of
staticfiles vs channels in INSTALLED_APPS.

Carl

-- 
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/57321974.7060207%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: DEPs (was: Making Django more PaaS-friendly)

[Carl Meyer]

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 features that don't have a DEP at all. For example
> database schemas and subquery expressions come to mind (these are
> ongoing work, PRs available at GitHub). There are various design
> choices and the features are somewhat significant, yet the design
> hasn't been at all DEP driven.

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, or if people in the community are
expressing concern about the feature or there's significant disagreement
about the design decisions that isn't quickly and easily resolved. When
there's a proposal to change a core aspect of Django in a pretty
fundamental way (like with multiple-template-engines or middleware),
that's a good case to just start out right away with a DEP, because it's
important to make really sure the community is on board with the change.
Again, I think DEPs ideally should be a useful tool, not a hoop to jump
through.

> Also, having DEP requested for channels only at this point, and Andrew
> (a technical board member) assuming a DEP wasn't required should point
> out there might be a problem. This is not to criticize Andrew but the
> way DEPs are sometimes required, sometimes not.

I didn't intend to be "requiring" a DEP for channels as some kind of
pro-forma dotting of the I's and crossing of the T's for a decision that
in practice had already been made; if that's how my message in that
thread came across, then I miscommunicated. I (strongly) suggested a
DEP, because when I looked back at e.g the discussion thread from
December I saw a number of concerns expressed about channels that still
didn't seem to me to have been resolved (and it also seemed clear from
messages from you and Mark that they weren't) and it seemed to me that
channels still needed the sort of focused public resolution of questions
and concerns that a DEP discussion can provide.

But it's quite possible I was just wrong in that suggestion. If in fact
all the important decisions are already made, and the only thing
channels really needs to address the concerns is real-world proving and
testing, then perhaps a DEP at this point is a waste of time. (Though a
DEP could also be a useful place to record and summarize the discussion
around the results of such real-world testing.)

> I'm not seeing a problem with the DEP idea in general, with any
> particular DEP or with any single feature having or not having a DEP.
> I'm criticizing the approach where sometimes patches are called out
> randomly for DEP, often at a point where the DEP is just documenting
> what has been already decided, not supporting the decision process
> itself.

Yeah, I certainly agree that the way it worked out for channels wasn't
ideal.

> I probably picked the wrong thread to complain about this - if we are
> going to want DEPs for features similar to the ideas discussed in this
> thread, then the timing for requesting a DEP was accurate.

Agreed.

Carl

-- 
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/573217E2.4010702%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Withdrawing Channels from 1.10

[Mark Lavin]

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 wrote:
>
> 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 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/c4fb72c3-0c41-472b-bdd2-2d462333e046%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Withdrawing Channels from 1.10

[Ryan Hiebert]

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 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/368C3DE9-64F2-4C17-8E17-CF5EF5529664%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Withdrawing Channels from 1.10

[Andrew Godwin]

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.

Instead, I will take the path-most-trodden for me and large Django
features, which is to run it as an external package, compatible with 1.8
through 1.10 (which the package already is), and let it mature and develop
outside of core, before coming round to look again at inclusion for 1.11 or
2.0.

My reasons are thus:

 - Trying to push it into 1.10 is either going to delay the release or
result in a rush job. We have time-based releases for a reason, and
stopping "big-name features" from sinking a release is one of those reasons.

 - There are numerous objections to the design, some well-founded. I'd like
to take time to prove out these decisions (or, indeed, refine them) with
channels in a more production situation and after a battery of load testing
and analysis.

 - 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 relatively minor.

 - The faster release cycle an external package can bring will almost
certainly be useful.

However, the step I'd like to take instead is moving Channels and its
associated project repos (daphne, asgiref, asgi_redis, asgi_ipc) under the
Django organisation on GitHub and discussing them openly in Django blog
posts, documentation and other places as the Django project's official way
to get WebSockets working - after all, we are paying people to work on it,
and I still remain convinced we need a solution.

I think this is a good mid-step, and given that you would have had to `pip
install` extra dependencies to get django.channels to run anyway, no more
complicated to use. I'd also propose that these external projects have
their own, shorter backwards-compatibility and security guarantees,
essentially running on a quicker, lighter version of the main release cycle.

That discussion is upcoming, but I wanted to retract the patch now because
I don't want us to get to the 15th May and be unsure about what's going on,
and there's plenty of other work we need to do to prep for the alpha.

Sorry about the drama I've stirred up these last few weeks; I had misjudged
the situation, and was more confident in the design and code than I maybe
should have been. A lot of the goals I want to achieve with Channels can be
done as an external package for now, and hopefully it will prove the
correct decision to take.

Andrew

-- 
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/CAFwN1uq7-E%2BLu5hCNQhoyO2W%3DvnPis7Q3sbqGo1xQ-%2BRmsFAgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Tom Christie]

> 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 features, you can just 
turn it on."

This isn't comparable to third-party packages, because it's a foundational 
aspect of the framework. Channels making its way into core is advantageous 
in a way that isn't nearly as true for other kinds of features.

> Political tirade follows

I don't think that discussion is likely to be a productive route to go 
down. Everyone here is motivated by the same desire to make Django be the 
best thing it can be. :)

-- 
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/df8906f9-d4ea-41b2-b2c5-57e500a1f01d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Yo-Yo Ma]

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-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/cd8c2845-d1bd-479d-8203-a742584d5954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Yo-Yo Ma]

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 a try. I had a quick 
honeymoon with it because I had been working on a game and was using aiohttp. 
aiohttp provides support for websockets but doesn't manage relationships 
between them, which makes it hard to do anything without building a layer in 
between your app and the web. This layer ends up being somethings like 
Channels. Channels basically accomplished what I needed, which I was ecstatic 
about.

The honeymoon ended when I started using Channels to experiment on my local 
machine. The notion that I would now have to use a data store to run my app at 
all didn't feel right, even though I knew there would need to be data stored to 
maintain relationships between websockets, etc. I was disheartened when I 
learned Channels was potentially going to be merged into Django, because I 
finally got to that realization of the fact that there wasn't a "right way" to 
include baked-in web sockets behind a web server, only to find out that 
Channels was going to be called the "right way", forever (potentially).

So, let me ask a question: how many of the past 5 paid projects you worked on 
required websockets? For me, and for most of the people I know (not many), the 
answer is 0. I can think of a use case where it would have been nice (the "how 
many other users are viewing this page" feature, which we accomplished with 
slow Ajax polling), but I can think of nothing critical.

I ask that question because a good argument came up earlier, a comparison to 
NoSQL. NoSQL was in the same must-have craze, and then the tried and true 
standard in Django (Postgres) sort of answered that with huge gains in 
performance and scalability. Competition is great for this reason, but merging 
in competion is sort of like a business acquiring innovative. competitors as 
they emerge; it doesn't do much to further the company's true vision, because 
it's a defensive move.

I would recommend against merging Channels now, and potentially ever; not 
because it's not great code, but because A) it isn't necessary for the core, B) 
leaving it out of the core doesn't prevent it from being used, and C) it should 
be proven over time as an outside package (a different way of solving this 
could come by and proliferate while we have Channels in core, and then Django 
would be heading back down that hill towards the bloat (e.g., contrib) it 
worked so hard to remove over the years - not that Django was ever *truly* 
bloated).

What I would recommend is that we focus on fixing/abstracting/documenting 
things that make it hard to integrate something like Channels (e.g., things 
that Andrew has to monkey patch, etc.), because Channels *and* a hypothetical 
future websockets package could both take advantage of such an abstraction 
layer.

Political tirade follows:

Another thing I would never recommend is letting a grant destroy Django's 
ability to make a decision on its own. It absolutely disgusts me to think of 
Django becoming like Firefox, with "features" like Pocket and Hello that are 
driven by financial or political desires. Django should continue to look 
unemotionally at feature requests without regard for sunk cost fallacy (e.g., 
" already spent X time working on this...", etc.).

-- 
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/bcbbf085-a11c-4894-a599-aa7867899e71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Tim Graham]

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:

Creating a "django.forms.renderers.templates.DefaultTemplateRenderer" 
(exact name to be discussed) which uses the fallback engines and ignores 
settings.TEMPLATES. This could be the default renderer for the FORM_RENDERER 
setting, for backwards-compatibility and to allow django.forms standalone 
usage by default. For more advanced uses, set the setting: FORM_RENDERER = 
'django.forms.renderers.templates.TemplateRenderer' (which uses 
django.template.loader.get_template and doesn't have any fallback engines).

On Tuesday, May 10, 2016 at 2:35:50 AM UTC-4, Aymeric Augustin wrote:
>
> I agree with Carl’s arguments about the fallback strategy (specifically, 
> the four paragraphs quoted below). 
>
> -- 
> Aymeric. 
>
> > On 10 May 2016, at 00:28, Carl Meyer  
> wrote: 
> > 
> > Yeah... so relatedly, you also mentioned in IRC and on GH that you don't 
> > see why we should deprecate the automatic fallback in case you don't 
> > have django.forms in INSTALLED_APPS and a loader with APP_DIRS=True. The 
> > answer to that, IMO, is that checking specifically for "django.forms in 
> > INSTALLED_APPS and APP_DIRS=True" is janky and inadequate, and I really 
> > don't think it belongs in there permanently. In fact I'm wondering now 
> > whether it even belongs in there temporarily as a deprecation path. 
> > 
> > The problem with that check is that there are various legitimate ways 
> > one could use the TemplateRenderer, and putting django.forms in 
> > INSTALLED_APPS and using a loader with APP_DIRS=True is only one of 
> > them. If you don't want to use APP_DIRS=True, it's also reasonable to 
> > put a separate engine in TEMPLATES pointing to the form templates (this 
> > might be a nicer solution for the Django test suite, for instance). Some 
> > people might even want to supply all their own form templates and not 
> > use any of the default ones, and that should be supported, too. By 
> > automatically overriding with our own fallback template engine if we 
> > don't detect "django.forms in INSTALLED_APPS and APP_DIRS=True", we 
> > effectively prohibit any other approach. I thought that might be OK as a 
> > temporary state of affairs during a deprecation path, but I definitely 
> > don't think it's OK permanently. 
> > 
> > I pushed an alternative approach in 
> > 
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
>  
> > that removes the INSTALLED_APPS checking. Instead, it has the `render` 
> > method unconditionally fallback to the built-in templates if a template 
> > is not found via the engines configured in TEMPLATES. 
> > 
> > I still think that in the long run, it's simpler and more predictable if 
> > the developer is simply responsible to either set up TEMPLATES such that 
> > the form templates needed are findable (startproject would set this up 
> > by default), or use a custom subclass of TemplateRenderer that does 
> > something entirely different. So I would still favor deprecating the 
> > fallback (in which case we should also update the startproject template 
> > so the fallback isn't needed for new projects). But I think this 
> > fallback is more flexible and simple enough that we could consider 
> > keeping it in place permanently, if you and others prefer that. 
>
>

-- 
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/8e52e3c9-f7dd-4b78-9ba8-66fcc0a7f9e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Tom Christie]

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 DEP and design discussion around it, sounds preferable to making a 
rushed judgement in either direction.

Cheers

  - Tom

-- 
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/7ab212b4-340d-41f3-a560-61831a9918e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Anssi Kääriäinen]

On Tue, May 10, 2016 at 4:54 AM, Andrew Godwin  wrote:
> My concern around using the Mozilla money to refine it was that it was
> applied for under the pretense this would be core Django, though if that's
> still our intention and we keep it external for now I don't see too much of
> a problem arising there.

I don't see a problem here - the main opposition seems to be about
having the code in Django 1.10. This puts a lot of pressure on Tim,
and there isn't enough time to field-test the design. It also feels
wrong that we approach many feature additions with saying that the
design should be proven in a 3rd party app, but there hasn't yet been
enough time to prove the channels design.

Tim's feeling about this is very important to me. He is doing an
awesome job reviewing and committing patches and ensuring releases
happen on time. In my opinion he should have control of what happens
near feature freeze. If he doesn't have that control, it will make it
impossible for him to ensure we stay on release schedule.

I'm going to try to avoid writing more about this. My opinion is
hopefully clear enough already. If the decision is to ship this in
1.10, then the available time should be used to make this feature as
good as possible, not on this discussion.

 - Anssi

-- 
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/CALMtK1GRgBGwhuEqhBf%3D%3DYyJr%2BF51dVo4CqerGPBNLfwu02hZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Aymeric Augustin]

I agree with Carl’s arguments about the fallback strategy (specifically,
the four paragraphs quoted below).

-- 
Aymeric.

> On 10 May 2016, at 00:28, Carl Meyer  wrote:
> 
> Yeah... so relatedly, you also mentioned in IRC and on GH that you don't
> see why we should deprecate the automatic fallback in case you don't
> have django.forms in INSTALLED_APPS and a loader with APP_DIRS=True. The
> answer to that, IMO, is that checking specifically for "django.forms in
> INSTALLED_APPS and APP_DIRS=True" is janky and inadequate, and I really
> don't think it belongs in there permanently. In fact I'm wondering now
> whether it even belongs in there temporarily as a deprecation path.
> 
> The problem with that check is that there are various legitimate ways
> one could use the TemplateRenderer, and putting django.forms in
> INSTALLED_APPS and using a loader with APP_DIRS=True is only one of
> them. If you don't want to use APP_DIRS=True, it's also reasonable to
> put a separate engine in TEMPLATES pointing to the form templates (this
> might be a nicer solution for the Django test suite, for instance). Some
> people might even want to supply all their own form templates and not
> use any of the default ones, and that should be supported, too. By
> automatically overriding with our own fallback template engine if we
> don't detect "django.forms in INSTALLED_APPS and APP_DIRS=True", we
> effectively prohibit any other approach. I thought that might be OK as a
> temporary state of affairs during a deprecation path, but I definitely
> don't think it's OK permanently.
> 
> I pushed an alternative approach in
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
> that removes the INSTALLED_APPS checking. Instead, it has the `render`
> method unconditionally fallback to the built-in templates if a template
> is not found via the engines configured in TEMPLATES.
> 
> I still think that in the long run, it's simpler and more predictable if
> the developer is simply responsible to either set up TEMPLATES such that
> the form templates needed are findable (startproject would set this up
> by default), or use a custom subclass of TemplateRenderer that does
> something entirely different. So I would still favor deprecating the
> fallback (in which case we should also update the startproject template
> so the fallback isn't needed for new projects). But I think this
> fallback is more flexible and simple enough that we could consider
> keeping it in place permanently, if you and others prefer that.

-- 
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/EFF3F90A-F111-4E1E-94FF-654008BBDD0A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: graphics artist (e.g. OmniGraffle) needed for updated middleware graphic

[Aymeric Augustin]

I’m the author of the current graphic. If it’s just a matter of tooling, I can 
take a sketch (e.g. a picture of hand-drawn diagram) and do it in a consistent 
style with the other graphic in the docs.

-- 
Aymeric.

> On 10 May 2016, at 03:48, Tim Graham  wrote:
> 
> Would someone like to help update the graphic in this section [0] for the 
> new-style middleware implemented in PR#6501 [1]. I'm not quite sure what the 
> updated graphic will look like yet, but there isn't any use thinking about 
> that if we don't have someone to do the work. :-) The existing image is done 
> in OmniGraffle [2] but I guess we're open to other solutions too.
> 
> [0] 
> https://docs.djangoproject.com/en/1.9/topics/http/middleware/#hooks-and-application-order
> [1] https://github.com/django/django/pull/6501
> [2] 
> https://github.com/django/django/tree/bf3057d10bc1e78a8e45142a8288a733b3e908a2/docs/topics/http/_images
> 
> -- 
> 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/890120ba-3f7e-40ad-86d0-f3f9c7a08a6b%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-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/E6019CC5-6351-4516-A7F0-AC2A2E59AEE4%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Claude Paroz]

Le mardi 10 mai 2016 00:28:57 UTC+2, Carl Meyer a écrit :
>
> I pushed an alternative approach in 
>
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
>  
> that removes the INSTALLED_APPS checking. Instead, it has the `render` 
> method unconditionally fallback to the built-in templates if a template 
> is not found via the engines configured in TEMPLATES. 
>

I didn't follow closely this work, but a definite +1 to a sane fallback 
(and keeping it). Having to fiddle with INSTALLED_APPS just to get forms 
rendered as before doesn't look nice to me. Sorry if I missed the point.

Claude

-- 
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/2176e758-864e-4d25-bb08-e51d17d4664d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Anssi Kääriäinen]

On Tue, May 10, 2016 at 1:48 AM, Carl Meyer  wrote:
> Hi Anssi,
>
> On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote:
> I'm curious to hear more about this - could you give some example DEPs
> where this was a problem? In the case of the two DEPs I was most closely
> involved with (multiple template engines and rethinking middleware), I
> don't think this is an accurate description of what happened. Both those
> DEPs were written relatively early in the design process and evolved as
> we learned from discussion and implementation.
> They were done quite similarly to how the PEPs I've worked on were done.
>
> I'm also curious about your use of the word "enforced." I don't really
> see the DEP process as something that needs "enforcement" (and I'm
> curious where you see it as having been lacking in "enforcement"). IMO
> the only relevant "enforcement," really, is that the implementation of a
> DEP which is rejected by the technical board (has never happened yet)
> should not be merged.

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 features that don't have a DEP at all. For example
database schemas and subquery expressions come to mind (these are
ongoing work, PRs available at GitHub). There are various design
choices and the features are somewhat significant, yet the design
hasn't been at all DEP driven.

Also, having DEP requested for channels only at this point, and Andrew
(a technical board member) assuming a DEP wasn't required should point
out there might be a problem. This is not to criticize Andrew but the
way DEPs are sometimes required, sometimes not.

I'm not seeing a problem with the DEP idea in general, with any
particular DEP or with any single feature having or not having a DEP.
I'm criticizing the approach where sometimes patches are called out
randomly for DEP, often at a point where the DEP is just documenting
what has been already decided, not supporting the decision process
itself.

I probably picked the wrong thread to complain about this - if we are
going to want DEPs for features similar to the ideas discussed in this
thread, then the timing for requesting a DEP was accurate.

  - Anssi

-- 
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/CALMtK1E9axuBW5y673LSAE3-2%2BUg45JcPL%2BNLQJVsUrjQ3aLzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.