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

[Andrew Godwin]

Good point. I'll get a proper DEP draft written up for next week and then
we can comment on it directly with more substance - it sounds like the idea
of having one is popular, though, which is what I mainly wanted to check!

Andrew

On Thu, May 12, 2016 at 12:52 PM, Marc Tamlyn  wrote:

> I'm a big fan of pulling things into github.com/django. One other point
> which has been raised when I've mentioned this before is the role of the
> django fellow(s) with regards to these projects. This should at least be
> touched on in the DEP.
>
> On 11 May 2016 at 20:34, William Hakizimana  wrote:
>
>> 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.
>>
>
> --
> 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/CAMwjO1Hiu3uYr2if4JP%2BoVMhVef%3D_J57dFdko6%2BpTzoDGMerLA%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/CAFwN1uphmqTZL2a6S%3D_gsMJ4Qd1Mtt4%2BvX23qK3tSzO2YHC7Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help Text Per Model Field Choice

[Marc Tamlyn]

Choices are currently very simple in core Django. There are multiple
 different
 packages
 which provide
alternative syntaxes or useful ideas for extending the concept. Python 3
also has enums  which are a
related concept. Personally, I have ideas for a class binding option
 useful when your
choices encapsulate functionality in your app - such as the help text. I've
also not yet written that package.

So, I feel this is only one of a wide range of issues which spring from the
simplicity of choices. It would be good to see a solution look at the range
of problems and prior art.

On 8 May 2016 at 12:53, David Sanders  wrote:

> Hey all,
>
> I think it would be a greatly useful feature to be able to set help text
> for choices on a model field.
>
> For the default Select widget this would be rendered as the title
> attribute for each choice, which browsers show when you hover over a
> choice. This also makes it simple to render the help text nicely using
> Select2, here's a quick example JSFiddle: https://jsfiddle.net/tt1a9zk6/
>
> Beyond Select, for rendering radio buttons it looks like title is also
> shown on hover by browsers, but it's a little less intuitive because you
> need to hover over the radio button, or put the title on the label instead.
> In admin, adding a little '?' icon like the one for the field help text on
> tabular inlines would would be a slick way to do it for radio buttons.
>
> Since the pattern for model field choices being a tuple is pretty
> ingrained and changing the plumbing to allow for an optional third value
> (the help text) would require a lot of change, I opted for using a tuple
> subclass to tack on the extra help text information. From the user
> perspective they'd still be providing tuples for the choices, with an
> optional third value.
>
> class FooBar(models.Model):
> STATUS_UNKNOWN = 0
> STATUS_SNAFU = 1
> STATUS_FUBAR = 2
>
> STATUSES = (
> (STATUS_UNKNOWN, _("Unknown")),
> (STATUS_SNAFU, _("SNAFU"), _("Situation Normal: All Fouled Up")),
> (STATUS_FUBAR, _("FUBAR"), _("Fouled Up Beyond All Recognition"))
> )
>
> status = models.IntegerField(choices=STATUSES, help_text=_("What's the
> current status?"))
>
> Under the covers the tuple gets converted to an instance of the class,
> which I called ChoiceTuple in my proof of concept patch (found at the end
> of this message). The help text gets set as an attribute on the instance so
> that it can be retrieved by aware widgets. If a widget isn't aware of the
> ChoiceTuple class, the choice acts like a two value tuple like it currently
> is. The only tricky bit is unwinding the choices value when it's broken
> into named groups, or is a callable, the code there is iffy, but it was
> just to get the proof of concept working.
>
> The nice thing about this approach is it also works nicely with
> ModelChoiceIterator, making it quick and easy to grab help text for choices
> populated from models in the DB off of one of the fields. This is useful
> for situations where the choices are a curated list in the database. The
> proof of concept patch tries to get the help text from a field on the model
> named help_text if present. That code wouldn't be included in the final
> patch, it's just an example.
>
> Thoughts? The addition of the class ChoiceTuple nicely minimizes the
> amount of changes needed to plumb the change all the way from the model
> field to the widget. I'm not married to the approach, I'm just looking for
> a clean way to allow help texts per choice.
>
> Proof of concept patch (based on current master):
> http://pastebin.com/90g6mUQ8
>
> - David
>
> --
> 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/CAEXbqgzhMj8kASksnO9nwFqJoNeMChV0X6ACuX8_OpOoX%3D0atg%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 

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

[Marc Tamlyn]

I'm a big fan of pulling things into github.com/django. One other point
which has been raised when I've mentioned this before is the role of the
django fellow(s) with regards to these projects. This should at least be
touched on in the DEP.

On 11 May 2016 at 20:34, William Hakizimana  wrote:

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

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

Re: Template-based widget rendering

[Carl Meyer]

On 05/12/2016 09:39 AM, Tim Graham wrote:
> So this discussion doesn't stall the rest of the patch, I suggest
> keeping the fallbacks for now and deprecation them later if they cause
> confusion or other problems.

Yes, I think that makes sense.

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


signature.asc
Description: OpenPGP digital signature

Re: Admin Themes in 1.10

[Tim Graham]

Seems okay to me.

On Sunday, May 8, 2016 at 11:19:43 AM UTC-4, David Sanders wrote:
>
> Ever since PR #5567 [1] (which is great, yay CSP) I've been concerned 
> about the impact it will invariably have on admin themes going forward. By 
> removing any inline JS, the various admin JS functionality is now 
> initialized in the JS files where it is much harder to extend or change for 
> an admin theme. None of the niceties of template blocks and extending 
> templates exist with the JS files, the only way to extend those would be to 
> duplicate the entire file, which is a non-starter from a maintenance 
> perspective. This cuts off the nice options added to these JS files since 
> themes can no longer effect these options.
>
> Possible ways to resolve this include:
>   * Move all JS initialization code to a single file which can be 
> overridden by an admin theme (still requires duplicating all of the 
> initialization code)
>   * Add an optional attribute to the relevant HTML which prevents the 
> initialization code from running, allowing themes to manually run 
> initialization code with custom options
>
> I'm a fan of the second option because it allows the most flexibility. An 
> admin theme can use custom options without duplicating much code, and a 
> custom TabularInline subclass can be created and use a custom template and 
> JS to provide custom options specific to that inline class.
>
> I've added a patch [2] which adds this functionality to the two admin 
> jQuery plugins which are most likely to be initialized with alternate 
> options: actions.js and inlines.js. For the former the attribute goes on 
> the div.actions and for the latter it goes on the 
> div.js-inline-admin-formset. I used the attribute 
> 'data-disable-document-ready', but the name could just as easily be 
> 'data-disable-auto-initialize' or something shorter if there's distaste for 
> the long names.
>
> Thoughts? I'd like to restore this ability to easily provide different 
> options to these admin jQuery plugins before 1.10 is finalized as it will 
> be harder to put the cat back in the bag if it ships without the ability.
>
> - David
>
> [1] https://github.com/django/django/pull/5567
> [2] http://pastebin.com/wcCk8T3n
>

-- 
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/efc498a9-c377-4f7a-b552-b9f353f0f17f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode normalization for username field

[Tim Graham]

Just to be sure, do you mean django.db.migrations (referencing the 
appropriate validator in the migration file, I guess?) or some problem a 
project would face when migrating from Python 2 to 3?

On Monday, May 9, 2016 at 4:00:27 PM UTC-4, Claude Paroz wrote:
>
> Le lundi 9 mai 2016 14:48:06 UTC+2, Tim Graham a écrit :
>>
>> Rather than change the behavior of Python 2 near its last supported 
>> version of Django, I would make the default validator ASCII on Python 2 and 
>> Unicode on Python 3.
>>
>
> I can buy this, providing we don't face migration issues.
>
> 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/a7362f65-146e-4515-95cd-5ef0fdbf78db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Tim Graham]

So this discussion doesn't stall the rest of the patch, I suggest keeping 
the fallbacks for now and deprecation them later if they cause confusion or 
other problems.

On Wednesday, May 11, 2016 at 2:08:31 PM UTC-4, Carl Meyer wrote:
>
> 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/4c27261f-5c08-4ac6-a6e3-4128a49f52d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.