Including or rendering templates with a non-default name without a ".tmpl" suffix fails

[brycelelbach]

You can include or render a template with the same name as the default templates without adding a ".tmpl" suffix. For example:

{% include "meta" %}

If I have a file meta.tmpl in my templates path, then it will get included.

However, if I try to include or render a template called custom.tmpl on my templates path that is NOT a default template, e.g.:

{% include "custom" %}
{% render("custom", child) %}

Then inja will throw an exception right here when parsing the template containing the above code, because it will be looking for /my/template/path/custom instead of /my/template/path/custom.tmpl.

I'm not sure how we could fix this. For the default templates, the mapping of "name" to "name.tmpl" happens because we explicitly parse the template and then add it to the inja environment with env->include_template("name", parsed_template). The dependencies of the default templates are hard-coded and then resolved in order.

But for non-default templates (both those with the same name as a default template and those with a different name), we don't know what their dependencies are, so we can't set this up.

Some possible solutions:

• Always add the ".tmpl" suffix when including/rendering and change the default templates and setup code to do this as well for consistency.
• Try to get inja to accept a PR adding support for suffixes that can be ignored - we'd have to modify this code

[matusnovak]

Yeah, the handling of templates by inja forced me to design it in this way. I would love to change how the custom templates are loaded, but I must take into account backwards compatibility. I can not change it and risk that someone's build will now suddenly fail.

Perhaps a v2.0 of the render and include function, which fixes all of these problems, that lives side by side with the old one. Would not break the compatibility.

I'll investigate and will come back to you.

[brycelelbach]

Yah I don't think it's a huge deal, no worries.

[brycelelbach]

#52 fixes this.