Re: Process DEP for "official" non-core projects

[William Hakizimana]

Just wanted to thank you so much for your hard work. The documentation is 
really well written!

On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote:
>
>
>
> On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss  
> wrote:
>
>> I like this, and +1 on your rough outline.
>>
>> There is one missing thing here though: I think we need to consider the 
>> process/policy for removing things if they're no longer maintained. Without 
>> clear maintainership forks happen, which is bad for pretty much everyone. 
>> So I think we should have a plan in place for what happens if the shepherd 
>> can no longer tend to their flock, and nobody else steps into the role.
>>
>> I'd suggest something like this: if a project goes stale, core calls for 
>> new maintainers. If none arrive within a reasonable period of time (3 
>> months?) we deprecate and remove the package from our org.
>>
>>
> That seems sensible to me; if the project is important enough to Django, 
> I'm sure people will step up to take over, and if not, dropping it is 
> probably the better option rather than letting it linger.
>
> I would be inclined to merely mark it as deprecated and not drop it from 
> e.g. the GitHub org, though, as where would we move it *to*? 
>
> 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/885bd485-341a-47ad-8766-7ef17df77ada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub Issues for DEP repository?

[Jacob Kaplan-Moss]

On Wed, May 11, 2016 at 1:11 PM, Carl Meyer  wrote:

> So I'd personally be
> fine with a PR to amend this section to remove mention of private
> contact. Jacob, I think you wrote this (or adapted it from PEP 1) -- any
> thoughts?
>

I don't recall why that's in there; I'm guessing it came over verbatim from
PEP 1 without much consideration. Yes, thumbs up on using public comms in
general.

Jacob

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

Re: Process DEP for "official" non-core projects

[Jacob Kaplan-Moss]

On Wed, May 11, 2016 at 2:29 PM, Andrew Godwin  wrote:

> I would be inclined to merely mark it as deprecated and not drop it from
> e.g. the GitHub org, though, as where would we move it *to*?
>

Sure, that's fine with me too. The key point is just that we're not
(implicitly or explicitly) offering support where there is none.

Jacob

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

Re: Process DEP for "official" non-core projects

[Andrew Godwin]

On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss 
wrote:

> I like this, and +1 on your rough outline.
>
> There is one missing thing here though: I think we need to consider the
> process/policy for removing things if they're no longer maintained. Without
> clear maintainership forks happen, which is bad for pretty much everyone.
> So I think we should have a plan in place for what happens if the shepherd
> can no longer tend to their flock, and nobody else steps into the role.
>
> I'd suggest something like this: if a project goes stale, core calls for
> new maintainers. If none arrive within a reasonable period of time (3
> months?) we deprecate and remove the package from our org.
>
>
That seems sensible to me; if the project is important enough to Django,
I'm sure people will step up to take over, and if not, dropping it is
probably the better option rather than letting it linger.

I would be inclined to merely mark it as deprecated and not drop it from
e.g. the GitHub org, though, as where would we move it *to*?

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

Re: Process DEP for "official" non-core projects

[Andrew Godwin]

On Wed, May 11, 2016 at 10:06 AM, Carl Meyer  wrote:

>
> I'm not quite sure what this means. By "major release" here, you mean
> "major release of the adopted project," not "major release of Django"?
> So this means that security fixes for the adopted project will be
> provided as patch releases on its current major release, but won't be
> backported beyond that?
>

Yes, my intention was of major releases for the non-core project. We could
always extend this to have the same level of coverage as Django; the
question is if we treat non-core projects as things that are provisionally
going into core and still maturing, or if we treat them as full projects in
their own right where the goal is not core integration (which might be
good).


>
> All of those points seem sensible to me, but I'd be interested in
> hearing from people who've already been actively involved in localflavor
> maintenance.
>

Me too - I'm not entirely clear what the state of maintenance and releasing
is like for it at the moment.

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

Re: Template-based widget rendering

[Carl Meyer]

On 05/11/2016 11:52 AM, Carl Meyer wrote:
> On 05/11/2016 11:30 AM, Tim Graham wrote:
>> What's your proposal for changing the default TEMPLATES? Using Jinja2 or
>> DTL?
> 
> At some point maybe we can adopt Jinja2 as a required dependency. Until
> then, the default startproject template can't use it, so I think DTL is
> the only real option.

Oops, I should clarify here that I don't actually plan to change the
default TEMPLATES setting at all; we don't need to. The default
startproject TEMPLATES already includes an engine with APP_DIRS: True; I
would just add 'django.forms' to the default INSTALLED_APPS.

But even that only really makes sense if we're planning to deprecate the
automatic fallback to the built-in templates, so we want to push people
to configure their settings to explicitly include them. If we plan to
leave the fallback around permanently, there's no need to change the
startproject template at all.

Here are the pros and cons as I see them for deprecating the fallback
(all the pros apply only after the deprecation process would complete):

- pro: cleaner and simpler default TemplateRenderer, with less complex
code and tests to maintain.

- pro: simpler mental model of form template rendering, where the form
templates work just like any other kind of template, they aren't
magically always available.

- con: requires an update to settings (for most projects, just adding
'django.forms' to INSTALLED_APPS) to keep forms rendering as they do now
(once the deprecation process completes).

I like conceptual simplicity, and I care more about where we end up than
about what the deprecation path requires (IMO the "con" in that list
disappears once everyone has upgraded through the deprecation process,
whereas the "pros" are permanent), so I lean towards deprecating the
fallback, but I really don't feel strongly about it at all. Claude
prefers keeping the fallback around permanently. What do others think?

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


signature.asc
Description: OpenPGP digital signature

Re: Process DEP for "official" non-core projects

[Jacob Kaplan-Moss]

I like this, and +1 on your rough outline.

There is one missing thing here though: I think we need to consider the
process/policy for removing things if they're no longer maintained. Without
clear maintainership forks happen, which is bad for pretty much everyone.
So I think we should have a plan in place for what happens if the shepherd
can no longer tend to their flock, and nobody else steps into the role.

I'd suggest something like this: if a project goes stale, core calls for
new maintainers. If none arrive within a reasonable period of time (3
months?) we deprecate and remove the package from our org.

Jacob

On Tue, May 10, 2016 at 10:58 PM, Andrew Godwin  wrote:

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

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

Re: Template-based widget rendering

[Carl Meyer]

On 05/11/2016 11:30 AM, Tim Graham wrote:
> I'm not sure about how common the need for custom widget templates are.
> Speaking for djangoproject.com and a few other small projects I
> maintain, I don't think these projects would make use of them but maybe
> if the feature is there, I might realize it would help in some places.

It's certainly not always needed; maybe "basic" is too strong a word.
Better to say that it's a very useful intermediate technique, especially
for more complex widgets with detailed UI needs.

We're not only talking about overriding templates for built-in widgets,
we're also talking about the ability to define your own custom widgets
with their own templates. If only the built-in widget templates are
available, you can't do that either. So given that templating is now the
norm for how to build widgets, we'd effectively be making it impossible
to create your own widget classes without changing the default form
renderer.

I'd flip it around and make the comparison with "standalone use of the
forms library without a configured TEMPLATES setting," which seems to be
the competing feature: is that really _more_ common than custom form
widgets? How many projects do you maintain that need that?

> What's your proposal for changing the default TEMPLATES? Using Jinja2 or
> DTL?

At some point maybe we can adopt Jinja2 as a required dependency. Until
then, the default startproject template can't use it, so I think DTL is
the only real option.

> Since others have supported the idea, feel free to push your ideas to
> the branch -- I won't be working on that branch for the rest of today.

Ok, will do.

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


signature.asc
Description: OpenPGP digital signature

Re: Template-based widget rendering

[Tim Graham]

I'm not sure about how common the need for custom widget templates are. 
Speaking for djangoproject.com and a few other small projects I maintain, I 
don't think these projects would make use of them but maybe if the feature 
is there, I might realize it would help in some places.

What's your proposal for changing the default TEMPLATES? Using Jinja2 or 
DTL?

Since others have supported the idea, feel free to push your ideas to the 
branch -- I won't be working on that branch for the rest of today.

On Tuesday, May 10, 2016 at 2:22:14 PM UTC-4, Carl Meyer wrote:
>
> 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/18c63161-f3de-44d5-aa4e-c91e3b63ec8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[Tim Graham]

I'm not targeting this for 1.10. The patch hasn't been under review and is 
likely too much to review in a couple days. Also documentation remains 
outstanding.

On Wednesday, May 11, 2016 at 12:52:33 PM UTC-4, Asif Saifuddin wrote:
>
> Can we expect this to be merged on 1.10 alpha? after that the minor 
> imporvements could be take place.
>
> Thanks
>
> On Monday, December 28, 2015 at 10:23:19 PM UTC+6, Marten Kenbeek wrote:
>>
>> Hi everyone,
>>
>> This past week I've made some great progress in rewriting the URL 
>> dispatcher framework and iterating on my implementation. A big part of my 
>> effort to refactor my original code was to increase the performance of 
>> reverse() to a level similar to the legacy dispatcher, and to decouple 
>> the various parts of the code. I think I have now achieved both goals, so 
>> I'd like to get some feedback on the result. 
>>
>> The current code can be found at 
>> https://github.com/django/django/pull/5578.
>>
>> I will be cleaning up the code and shuffling around some of it. There's 
>> still a lot to be done, but the high-level design and public API are pretty 
>> much finished and ready for review. 
>>
>> The API consists of 4 parts, most of which are extendible or replaceable: 
>> a Dispatcher, a set of Resolvers, Constraints and the URL configuration. 
>>
>> The main entry point for users is the Dispatcher class. The dispatcher 
>> is responsible for resolving namespaces and reversing URLs, and handles 
>> some of the utility functions available to users (some more may be moved 
>> here, such as is_valid_path() or translate_url()). It is a thin wrapper 
>> around the root Resolver to allow a single entry point for both reversing 
>> and resolving URLs. It currently provides the following public API:
>>
>>- Dispatcher.resolve(path, request=None) -> Resolve path to a 
>>ResolverMatch, or raise Resolver404. 
>>- Dispatcher.resolve_namespace(viewname, current_app=None) -> Resolve 
>>the namespaces in viewname, taking current_app into account. Returns 
>>resolved lookup in a list.
>>- Dispatcher.reverse(lookup, *args, **kwargs) -> Reverse lookup, 
>>consuming *args and **kwargs. Returns a full URL path or raises 
>>NoReverseMatch. 
>>- Dispatcher.resolve_error_handler(view_type) -> Get error handler 
>>for status code view_type from current URLConf. Fall back to default 
>>error handlers. 
>>- Dispatcher.ready -> (bool) Whether the dispatcher is fully 
>>initialized. Used to warn about reverse() where reverse_lazy() must 
>>be used. 
>>
>> I'm currently looking into possible thread-safety issues with 
>> Dispatcher.load_namespace(). There are some parts of Django that depend 
>> on private API's of Dispatcher and other parts of the dispatching 
>> framework. To maximize extensibility, I'll look if these can use public 
>> API's where appropriate, or gracefully fail if a swapped-in implementation 
>> doesn't provide the same private API. One example is admindocs, which uses 
>> the Dispatcher._is_callback() function for introspection. 
>>
>> If a developer wishes to completely replace the dispatcher framework, 
>> this would be the place to do it. This will most likely be possible by 
>> setting request.dispatcher to a compatible Dispatcher class. 
>>
>> The BaseResolver class currently has two implementations: Resolver and 
>> ResolverEndpoint. The resolver's form a tree structure, where each 
>> resolver endpoint is a leaf node that represents a view; it's job is to 
>> resolve a path and request to a ResolverMatch. Users will mostly use 
>> this through Dispatcher.resolve(), rather than using it directly. Its 
>> public API consists of two functions:
>>
>>- BaseResolver.resolve(path, request=None) -> Return a ResolverMatch or 
>>raise Resolver404.
>>- BaseResolver.describe() -> Return a human-readable description of 
>>the pattern used to match the path. This is used in error messages. 
>>
>> There is a slightly more extensive API that allows a resolver to "play 
>> nice" with Django's resolver implementations. This allows a developer to 
>> replace a single layer of resolvers to implement custom logic/lookups. For 
>> example, you can implement a resolver that uses the first hierarchical 
>> part of the path as a dict lookup, rather than iterating each pattern. To 
>> make this possible, a resolver should accept the following arguments in its 
>> constructor:
>>
>>- BaseResolver.__init__(pattern, decorators=None) -> pattern is a 
>>URLPattern instance (explained below). decorators is a list of 
>>decorators that should be applied to each view that's a "descendant" of 
>>this resolver. This list is passed down so the fully decorated view can 
>> be 
>>cached. 
>>
>> I'm still looking how exactly we'd allow a developer to hook in a custom 
>> resolver, any ideas are welcome. 
>>
>> Constraints are the building blocks of the current dispatcher framework. 
>> A Constraint 

Re: re-thinking middleware

[Carl Meyer]

On 05/10/2016 03:37 PM, Carl Meyer wrote:
> 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

Better version of this link (to exclude more recent changes to other
DEPs in master):
https://github.com/django/deps/compare/763530e1a9...77c93d46baf

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


signature.asc
Description: OpenPGP digital signature

Re: GitHub Issues for DEP repository?

[Carl Meyer]

Hi Kevin,

On 05/10/2016 11:24 PM, Kevin Christopher Henry wrote:
> 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?

Given that DEP 1 specifically mentions using GH issues to comment on
DEPs, I'm considering this a bug/oversight: I went ahead and enabled GH
issues on the DEPs repo. Thanks for pointing it out!

> 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 agree with this: I think it's better to encourage keeping things in
public rather than encourage privately contacting DEP authors (as a DEP
author, I'd certainly rather have suggestions made in public than be
contacted privately, even in early draft stages). So I'd personally be
fine with a PR to amend this section to remove mention of private
contact. Jacob, I think you wrote this (or adapted it from PEP 1) -- any
thoughts?

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


signature.asc
Description: OpenPGP digital signature

Re: Process DEP for "official" non-core projects

[Carl Meyer]

On 05/10/2016 08:58 PM, Andrew Godwin wrote:
> 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.

Makes sense to me.

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

I'm not quite sure what this means. By "major release" here, you mean
"major release of the adopted project," not "major release of Django"?
So this means that security fixes for the adopted project will be
provided as patch releases on its current major release, but won't be
backported beyond that?

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

All of those points seem sensible to me, but I'd be interested in
hearing from people who've already been actively involved in localflavor
maintenance.

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


signature.asc
Description: OpenPGP digital signature

Re: URL dispatching framework: feedback requested

[Asif Saifuddin]

Can we expect this to be merged on 1.10 alpha? after that the minor 
imporvements could be take place.

Thanks

On Monday, December 28, 2015 at 10:23:19 PM UTC+6, Marten Kenbeek wrote:
>
> Hi everyone,
>
> This past week I've made some great progress in rewriting the URL 
> dispatcher framework and iterating on my implementation. A big part of my 
> effort to refactor my original code was to increase the performance of 
> reverse() to a level similar to the legacy dispatcher, and to decouple 
> the various parts of the code. I think I have now achieved both goals, so 
> I'd like to get some feedback on the result. 
>
> The current code can be found at 
> https://github.com/django/django/pull/5578.
>
> I will be cleaning up the code and shuffling around some of it. There's 
> still a lot to be done, but the high-level design and public API are pretty 
> much finished and ready for review. 
>
> The API consists of 4 parts, most of which are extendible or replaceable: 
> a Dispatcher, a set of Resolvers, Constraints and the URL configuration. 
>
> The main entry point for users is the Dispatcher class. The dispatcher is 
> responsible for resolving namespaces and reversing URLs, and handles some 
> of the utility functions available to users (some more may be moved here, 
> such as is_valid_path() or translate_url()). It is a thin wrapper around 
> the root Resolver to allow a single entry point for both reversing and 
> resolving URLs. It currently provides the following public API:
>
>- Dispatcher.resolve(path, request=None) -> Resolve path to a 
>ResolverMatch, or raise Resolver404. 
>- Dispatcher.resolve_namespace(viewname, current_app=None) -> Resolve 
>the namespaces in viewname, taking current_app into account. Returns 
>resolved lookup in a list.
>- Dispatcher.reverse(lookup, *args, **kwargs) -> Reverse lookup, 
>consuming *args and **kwargs. Returns a full URL path or raises 
>NoReverseMatch. 
>- Dispatcher.resolve_error_handler(view_type) -> Get error handler for 
>status code view_type from current URLConf. Fall back to default error 
>handlers. 
>- Dispatcher.ready -> (bool) Whether the dispatcher is fully 
>initialized. Used to warn about reverse() where reverse_lazy() must be 
>used. 
>
> I'm currently looking into possible thread-safety issues with 
> Dispatcher.load_namespace(). There are some parts of Django that depend 
> on private API's of Dispatcher and other parts of the dispatching 
> framework. To maximize extensibility, I'll look if these can use public 
> API's where appropriate, or gracefully fail if a swapped-in implementation 
> doesn't provide the same private API. One example is admindocs, which uses 
> the Dispatcher._is_callback() function for introspection. 
>
> If a developer wishes to completely replace the dispatcher framework, this 
> would be the place to do it. This will most likely be possible by setting 
> request.dispatcher to a compatible Dispatcher class. 
>
> The BaseResolver class currently has two implementations: Resolver and 
> ResolverEndpoint. The resolver's form a tree structure, where each 
> resolver endpoint is a leaf node that represents a view; it's job is to 
> resolve a path and request to a ResolverMatch. Users will mostly use this 
> through Dispatcher.resolve(), rather than using it directly. Its public 
> API consists of two functions:
>
>- BaseResolver.resolve(path, request=None) -> Return a ResolverMatch or 
>raise Resolver404.
>- BaseResolver.describe() -> Return a human-readable description of 
>the pattern used to match the path. This is used in error messages. 
>
> There is a slightly more extensive API that allows a resolver to "play 
> nice" with Django's resolver implementations. This allows a developer to 
> replace a single layer of resolvers to implement custom logic/lookups. For 
> example, you can implement a resolver that uses the first hierarchical 
> part of the path as a dict lookup, rather than iterating each pattern. To 
> make this possible, a resolver should accept the following arguments in its 
> constructor:
>
>- BaseResolver.__init__(pattern, decorators=None) -> pattern is a 
>URLPattern instance (explained below). decorators is a list of 
>decorators that should be applied to each view that's a "descendant" of 
>this resolver. This list is passed down so the fully decorated view can be 
>cached. 
>
> I'm still looking how exactly we'd allow a developer to hook in a custom 
> resolver, any ideas are welcome. 
>
> Constraints are the building blocks of the current dispatcher framework. A 
> Constraint can (partially) match a path and request, and extract 
> arguments from them. It can also reconstruct a partial URL from a set of 
> arguments. Current implementations are a RegexPattern, 
> LocalizedRegexPattern, LocalePrefix and ScriptPrefix. This is the main 
> extension point for developers. I envision that over time, Django will 

Re: Template-based widget rendering

[Preston Timmons]

Hey Curtis,

I think you're asking how this patch will help with form and field layouts?
If so, not that much. It only addresses moving the widget HTML that
currently is hardcoded in Python into templates.

For example, compare:

https://github.com/django/django/blob/master/django/forms/widgets.py#L272

to the template version:

https://github.com/django/django/blob/15667/django/forms/templates/django/forms/widgets/input.html

It also enables easier custom widgets, like the admin clearable file input:

https://github.com/django/django/blob/15667/django/contrib/admin/templates/admin/widgets/clearable_file_input.html

There's nothing in this patch that would hinder further development to
convert the form rendering methods, like `Form.as_p()` to be template
based also, or providing better rendering methods altogether.

With that said, yes the renderer class is able to be set per form class
and as an argument to `Form.__init__()`.

Preston



On Tuesday, May 10, 2016 at 10:32:30 PM UTC-5, Curtis Maloney wrote:
>
> 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 
>

-- 
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/856af7b0-9d1e-485b-ac57-e37f4d4cee04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.