Cross Backend template includes are not supported

[Paul Hallett]

Attempting to render Jinja templates with an include tag in a Django template results in the Django template backend parsing the jinja template.

For example:

templates/django.html:

Django Template!
{% include 'include.jinja' %}

jinja2/include.jinja:

Jinja Template!
{% set jinja = 1 %}

Will cause a template rendering error as set is not a valid tag in Django templates.

This used to work fine as the IncludeNode that powers the include tag would search using all configured loaders but since 1.8 it has changed to maintain the current engine context.

This seems like an obvious behaviour to want and we've relied on it heavily while porting our templates from Django to Jinja2 but this is now blocked by this change in 1.8.

[Aymeric Augustin]

Replying to phalt:

Attempting to render Jinja templates with an include tag in a Django template results in the Django template backend parsing the jinja template.

That's the intended behavior. The support for multiple template engines was designed that way because it isn't possible to mix arbitrary templates engines in general.

This used to work fine as the IncludeNode that powers the include tag would search using all configured loaders but since 1.8 it has changed to maintain the current engine context.

I'm not really buying this argument. Django 1.7 didn't have built-in support for Jinja2. Perhaps it worked with some third-party library, but as far as Django is concerned, the {% include %} tag was never documented to load anything other than Django templates.

This seems like an obvious behaviour to want

To me this seems like an obvious behavior not to want because it isn't symmetrical. Unless I missed something or you're using a library I don't know about, you can include Jinja templates from Django templates but you can't include Django templates from Jinja templates. I wouldn't call this asymmetry obvious.

and we've relied on it heavily while porting our templates from Django to Jinja2 but this is now blocked by this change in 1.8.

I'm sorry, but I disagree with some aspects of the design of the third-party library I suspect you're using. Switching from that library to the built-in support requires some changes.

In my opinion, the correct design for your use case is to implement a {% jinja2_include %} tag that makes it explicit that you're switching engines. It appears that you're identifying templates by their file extensions. It shouldn't be too hard to implement such a tag and run a big replace-all to use it wherever necessary.

One of the goals of refactoring the template engine was to make it a standalone library. It works without Django settings. The {% include %} tag cannot know which template engines are configured without breaking this property. That's another reason for preferring a distinct {% jinja2_include %} tag.

For all these reasons, I'm rejecting the idea of changing the behavior of the Django template language's {% include %} tag.

If you aren't convinced and you want to continue this discussion, I recommend taking it to the django-developers mailing-list in order to get a wider audience. Thanks !

[Alex Stapleton]

In my opinion, the correct design for your use case is to implement a {% jinja2_include %} tag that makes it explicit that you're switching engines.

That's an acceptable solution. Thanks for the help :)