Hi Tim, On 05/09/2016 08:03 AM, Tim Graham wrote: > I've been working on testing and writing documentation for Preston's PR: > https://github.com/django/django/pull/6498 > > About backwards compatibility, the current implementation which seems to > be based on Carl's proposal requires either a) 'django.forms' in > INSTALLED_APPS (so the APP_DIRS loader can find the DTL widget > templates) or b) Jinja2 to be installed so that the > TemplateRenderer.default_engine() initialization of Jinja2 doesn't fail. > If these items were accepted and acknowledged as upgrade requirements, > it wasn't clear to me.
Nope, I just overlooked the "Jinja2 is not installed" case there. In that case we should just use a DjangoTemplates engine instead of a Jinja2 engine as the fallback, which is what you've done in https://github.com/django/django/pull/6498/commits/83e0138a85ada2a8139af8a35629b78ec5e539d8 > In trying to make the Django test suite pass without Jinja2 installed, I > noticed that the 'django.forms' in INSTALLED_APPS requirement is a bit > annoying because this requires any use of > @override_settings(INSTALLED_APPS=[...]) that does widget rendering to > now include 'django.forms'.<https://github.com/django/django/pull/6498> 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. (I also removed the whole engine_name thing in that commit; it doesn't really seem worth it. If you're subclassing TemplateRenderer, it's easy enough to just override get_template and do whatever you like.) If you like that approach, I can re-add some TemplateRenderer tests and update the docs and push it to the main `15667` branch. 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/57310F15.2060401%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
