"Tolerant mode": How to make two successive Jinja2 engines run on the same template file?

[fralau]

Situation

I realize that the following question could seem daffy at first, but bear with me:

1. Assume a template file, which contains calls to the functions foo(), bar(), baz() as well as foobar() and foobaz() (the names do not have any special implication) e.g, {{ foo('hello world') }}.

2. For reasons which I will soon explain, there is not one but two Jinja2 template engines A and B operating on it, in succession (order arbitrary). The context of A is able to interpret the functions foo(), bar() and baz(), and B knows how to handle foobar() and foobaz().

If we try to run A, it will fail on foobar() and foobaz(), return a blank string or do any number of things, which all result in the fact that when we run B, we will also not get what we expect. Similarly, when we run first B and then A.

### Problem

The problem is that this issue does exists in real life, on modular systems such as MkDocs which load lists of plugins at run-time. Anyone can write plugins and anyone can mix and match them on their own project; so it is inevitable that sooner or later (as it happened) several developers will indepently stumble onto the great (and self-evident) idea of using Jinja2 in a plugin to implement the particular functionality they need!

As a result, we have a number of different successive calls to distinct Jinja2 engines within MkDocs (or to analogous self-developed parsing tools which are all based on the same curly bracket syntax), each implementing one or two functions... confusion ensued with incompatible plugins, or elaborate protocols of which should be called first, etc.

Certainly, we could advise them to federate all their developments under the umbrella one common template engine, and this is exactly what I did by implementing MkDocs Macros!

However, the Open Source world is a republic, not a tyranny. We cannot force other developpers to do things that would seem logical or desirable from our perspective, but that might not even be (in the final analysis) in their best interests!

This situation could potentially occur in any deployment environment, where there is a pipeline of processing steps on a text file, each using Jinja2 to solve a distinct, specific problem.

Solution

So, could we find an elegant solution to that problem of conflicting template engines?

I would propose the following opt-in behavior when running a Jinja2 template engine in a context of potential conflicts (we could call it non-exclusive (or tolerant) mode):

1. If all function/filters exist (can be found in the template engines context), proceed to execute the statement.
2. If all function/filters exist but the statement raises some exception (because of faulty arguments or whatever reason), use the standard options to process it, as done today in Jinja2.
3. If a any function/or filter does not exist, leave the whole string {{ foo('hello world') }} untouched and proceed.

Then the question of "what happens if some statement was not interpreted in the end?" is one that can be solved in plenty of ways, according to the needs. Clearly, the API should provide a list of the uninterpreted statements.

What do you think?

[fralau]

After more thought, there could be an elegant solution: to introduce an enclosing statement with a context name, something like:

{% context A %}

{% for user in users %}
  <li>{{ foo('user') }}</li>
{% endfor %}

{% endcontext %}

Then we could instruct a specific Jinja2 engine to run only the statements/expressions of one or more specific contexts, or converselly all statements/expressions that are not in a specific context.

Though I know that only asking to use {% raw %} and {% endraw %} in existing files is already unpopular. 🤔 The "tolerant mode" might still be desirable, as a default and failsafe mechanism.