Re: re-thinking middleware
The technical board has approved DEP 5, and since the patch [1] is also ready to go, I moved it straight to Final state. Thanks to everyone who contributed to the discussion, and especially to Florian and Tim for the patch. Carl [1] https://github.com/django/django/pull/6501 -- 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/22c30cb0-7a3e-4622-9302-294170ec92a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [RFC] Test methods filtering on tests run
Hi Antonio I have the same problem when running tests in Django's test suite. When there's a failure, I have to copy the test path, paste that, then copy the failing test. The entire path to the test isn't printed in the failures. I'd be a big fan of *some* kind of implementation that allows me to filter test methods. I think I'd prefer some kind of glob syntax though, so I could do: ./manage.py test app_package**test_method That would allow you to be as targeted as you needed to be. Would you mind posting your patch somewhere? Reviewing code along with the description and seeing potential for changes would be cool. Josh -- 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/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Template-based widget rendering
Hi Tim,
On 05/14/2016 08:03 AM, Tim Graham wrote:
> While testing this, I ran into a shortcoming with the fallback strategy
> for backwards-compatibility.
>
> If you have a DjangoTemplates backend configured with 'APP_DIRS': True
> (as in the tutorial) and you try to visit /admin/auth/user/#/change/
> which renders the ReadOnlyPasswordHashWidget, the template system will
> crash with TemplateDoesNotExist because it can find the widget's
> template using the app_directories loader but not the
> 'django/forms/widgets/attrs.html' template that the first template
> includes. Since the first template is found using what's configured in
> TEMPLATES (which doesn't know about any of the built-in form templates),
> the standalone engine needed to find the built-in templates is ignored.
>
> I guess it will affect every project that uses the admin. I can't think
> of a simple solution other than adding a system check upgrade warning to
> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not
> 'django.forms') and advise the user to add 'django.forms' to
> INSTALLED_APPS. Thoughts?
Yuck. Is there only one admin widget that includes a built-in widget? If
so, I think we would maybe be better off just duplicating that one
built-in widget in the admin templates. Obviously that's not ideal, but
I think it's better than giving up on seamless backward compatibility.
Then obviously we need to add a note to the documentation clarifying
that if you have any custom form templates that need to include or
extend any of the default templates, you should put 'django.forms' in
INSTALLED_APPS so all of the templates can be found by the same template
engine.
This might be another argument in favor of deprecating the fallback and
actively pushing people to just get 'django.forms' into their
INSTALLED_APPS. But we can wait on that, like you said.
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/57394559.70508%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
[RFC] Test methods filtering on tests run
Hello everyone, my name is Antonio, I'm using Django 1.9 and first of all I'd like to thank you all contributors for the amazing framework I can work with. I've just joined the django-dev mailing list to ask your opinion on a really trivial patch I thought implementing. Our backend server has with several apps: each app has its own test package; each test package has several modules; each module has several classes that has several methods. In short, when we need to run tests we rarely run: $ python manage.py test mydjangoapp.app_one.tests More likely we run: $ python manage.py test \ mydjangoapp.app_one.tests.test_module.TestClass.test_method_1 This happens especially when we need to investigate a regression, we need to do a lot of writing because single tests are failing and we just need to run that very test. So I thought that it could be very useful a shortcut to get to the "test_method_1" without writing the full CamelCased namespace all the way down there. I hacked together as proof a patch that adds an optional parameter to the Django Command test.py: $ python manage.py test --method-filter test_method_1 this can be a comma separated list of methods: $ python manage.py test --method-filter test_method_1,test_method_2,... Basically this patch rewrites the TestSuite object created in DiscoverRunner.run_test(), filtering out method names that do not match that list. Of course in case of name clashes two test methods from different apps will run, but I don't find it an issue as we give meaningful names to test methods. Also, there are many ways that such a check could be implemented to give it flexibility (albeit simple). So far I find it quite useful, but maybe because this patch solves a very narrow use case (mine :-)) but I would like to know if 1) I missed an already implemented way for such thing and if not 2) would you be interested in a pr with such a patch. Thanks for your comments, thoughts, suggestions, etc. Sorry for the long post. Regards, Antonio -- 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/573A53C9.9090702%40storiepvtride.it. For more options, visit https://groups.google.com/d/optout.
Re: Template-based widget rendering
Carl, there are other widgets such as
admin/widgets/related_widget_wrapper.html which include the built-in widget
templates. It's actually a variable include, {% include
widget.template_name %}, so copying the included template isn't feasible in
this case.
Claude, I'm not quite sure what the implementation of your idea would look
like. One possibility would be automatically add the form template
directories in each template engine's 'DIRS' [0]. This doesn't seem like a
good separation of concerns though.
[0]
https://github.com/django/django/blob/aa69f36984adb6cba5763604150d99e89aa1ee71/django/template/backends/django.py#L32
On Monday, May 16, 2016 at 12:18:44 PM UTC-4, Claude Paroz wrote:
>
> ...always consider templates (not forms, sorry ) in django.forms ...
>
--
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/ba5cea4b-8d15-49ca-bc71-ea040a4653e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Template-based widget rendering
...always consider templates (not forms, sorry ) in django.forms ... -- 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/9c69034d-c12e-4c05-a7ea-e78fd52a6b88%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Template-based widget rendering
Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit :
>
> (...)
>
> I guess it will affect every project that uses the admin. I can't think
> of a simple solution other than adding a system check upgrade warning to
> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not
> 'django.forms') and advise the user to add 'django.forms' to
> INSTALLED_APPS. Thoughts?
>
I'm still answering with my naive hat: isn't it possible to simply always
consider forms in django.forms without requiring anything new in
INSTALLED_APPS? What would be the problem? (Sorry if I missed a discussion
about that).
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/65f588d1-fd03-4bb4-aad5-733e680b5541%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
