Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Robert Roskam
+1 On Wednesday, December 7, 2016 at 11:25:05 AM UTC-5, Marc Tamlyn wrote: > > What Aymeric and Florian sayid. > > On 7 December 2016 at 15:58, Florian Apolloner > wrote: > >> On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin >> wrote: >>> >>> I still think I wouldn't use a dj

Re: Template-based widget rendering

2016-12-07 Thread Carl Meyer
Hi Tim, On 12/07/2016 08:41 AM, Tim Graham wrote: > This scheme seems to be working well so far. Great, thanks for working on implementation. I did have intentions of putting together the implementation once I'd gotten your feedback on the design, but I won't complain if you've already done it :-

Re: Template-based widget rendering

2016-12-07 Thread Tim Graham
This scheme seems to be working well so far. One thing you may not have thought of is that switching to JinjaTemplateRenderer is incompatible with the admin because jinja2 templates aren't provided for those widgets. I think the reasoning was that they're complicated to convert due to the use o

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Marc Tamlyn
What Aymeric and Florian sayid. On 7 December 2016 at 15:58, Florian Apolloner wrote: > On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote: >> >> I still think I wouldn't use a django_ prefix when I create new apps >> because >> it adds a small but pervasive overhead to p

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Florian Apolloner
On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote: > > I still think I wouldn't use a django_ prefix when I create new apps > because > it adds a small but pervasive overhead to prevent conflicts that aren't > common > in practice. > Same here, I am certainly against

Re: Good morning Django team!

2016-12-07 Thread Tim Graham
Hi Adonys, If you want to help out, you can look at the "Patches needing review" queue (currently 28 issues) at https://dashboard.djangoproject.com/ and help to review those patches using the patch review checklist [0]. Reviewing patches isn't a task limited to members of the Django team. Anyon

Good morning Django team!

2016-12-07 Thread Adonys Alea Boffill
I have a ticket #26543 ready for make the last review a week ago, I added the pull-request to the ticket. I know you have a lot of task to complete, this email is only to make a reminder. Thanks in advance an

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Aymeric Augustin
> On 7 Dec 2016, at 12:52, Raphael Hertzog wrote: > > And the mismatch between package name and module name means that we have > many packages which are not co-installable because they use the same > python module name. Yes that’s an issue. While it isn't specific to Django, the current practice

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Raphael Hertzog
Le mercredi 07 décembre 2016, Aymeric Augustin a écrit : > In my experience: > > - many Django-related packages use a django- prefix in the name of the package > on PyPI And the mismatch between package name and module name means that we have many packages which are not co-installable because t

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Aymeric Augustin
Hello Raphael, > On 7 Dec 2016, at 11:39, Raphael Hertzog wrote: > > Would you agree to add this recommendation somewhere in the official > Django doc? In my experience: - many Django-related packages use a django- prefix in the name of the package on PyPI - very few use a django_ prefix i

Guidelines to name python modules of Django applications?

2016-12-07 Thread Raphael Hertzog
Hello, in Debian we recently had a discussion about the package name we use for Django applications/extensions, it's usually python-django-. But the generic naming policy we have for all Python modules implies that this package would provide a "django_foo" Python module and this is not always the