Template cache, {% extends %} and globals - design issue?

[miracle2k]

Say I have this template with an extends call:

foo.html:

{% extends 'base.html' %}

I load it:

jinja2_env.get_template('foo.html', globals=my_globals}

This causes two calls to Environment._load_template: First, for foo.html, the for base.html.

Environment._load_template caches both templates.

The crucial point is that for the second call, the "globals" parameter to Environment._load_template is missing my_globals.

If I now attempt to load the base template directly:

jinja2_env.get_template('base.html', globals=my_globals}

The cache will be used, and my globals will not be available.

Using 2.7.2

[mitsuhiko]

Yes. This is currently the case. This is related to the general problems with scoping in Jinja2 that need to be tackled. Unfortunately that is a very big change and I am not sure how to fix this without spending a lot of time on it.

[dsedivec]

Here are a couple observations for anyone who runs into this in the future, as I have just this evening.

If you do @miracle2k's steps in the opposite order, that could be equally problematic: If you first instantiate base.html with a particular set of globals, but then subsequently instantiate foo.html, base.html will still have its original set of globals, which might be somewhere between unexpected and dangerous.

Of course, I'm pretty sure this breaks as well. Is it documented somewhere that you shouldn't call get_template for the same template with different globals? It's very possible I missed it.

globals_1 = {"x": 42}
globals_2 = {"y": 101}
jinja2_env = jinja2.Environment(loader=jinja2.FileSystemLoader("."))
instance_1 = jinja2_env.get_template("foo.html", globals=globals_1)
instance_2 = jinja2_env.get_template("foo.html", globals=globals_2)
# This fails because instance_1.globals is instance_2.globals.
assert "y" in instance_2.globals

I think you can get around these problems with template globals in exchange for a ~10x performance hit by using a byte code cache and disabling cache_size=0 on your Environment. Example:

class MemoryBytecodeCache(jinja2.BytecodeCache):
    def __init__(self):
        self._cache = {}

    def load_bytecode(self, bucket):
        try:
            bucket.code = self._cache[bucket.key]
        except KeyError:
            return

    def dump_bytecode(self, bucket):
        self._cache[bucket.key] = bucket.code

jinja2_env = jinja2.Environment(
    loader=jinja2.FileSystemLoader("."),
    cache_size=0,
    bytecode_cache=MemoryBytecodeCache(),
)
instance_1 = jinja2_env.get_template("foo.html", globals=globals_1)
instance_2 = jinja2_env.get_template("foo.html", globals=globals_2)
# This now tests true, like I originally expected.
assert "y" in instance_2.globals

Here's a hasty benchmark showing the cost of disabling the template cache (macOS, 2020 MacBook Pro, Python 3.8):

Testing with template cache, without byte code cache
Time per call for  50000 loops:     5.40 μs     5.49 μs     5.55 μs     6.65 μs     7.52 μs
Testing without template cache, without byte code cache
Time per call for    200 loops:   969.33 μs   979.95 μs   999.58 μs  1036.58 μs  1142.10 μs
Testing with template cache, with byte code cache
Time per call for  50000 loops:     5.28 μs     5.41 μs     5.43 μs     5.62 μs     6.68 μs
Testing without template cache, with byte code cache
Time per call for   5000 loops:    44.04 μs    44.31 μs    45.37 μs    46.86 μs    51.69 μs

Code that produced that:

def run_silly_benchmark(*timer_args, repeat=5, **timer_kwargs):
    timer = timeit.Timer(*timer_args, **timer_kwargs)
    num_times, time_taken = timer.autorange()
    times = [time_taken]
    for _ in range(1, repeat):
        times.append(timer.timeit(num_times))
    print(
        f"Time per call for {num_times:6d} loops: ",
        "  ".join(
            f"{(time * 10**6) / num_times:7.2f} μs" for time in sorted(times)
        ),
    )


loader = jinja2.FileSystemLoader(".")
for env in (
    jinja2.Environment(loader=loader),
    jinja2.Environment(loader=loader, cache_size=0),
    jinja2.Environment(loader=loader, bytecode_cache=MemoryBytecodeCache()),
    jinja2.Environment(
        loader=loader, cache_size=0, bytecode_cache=MemoryBytecodeCache()
    ),
):
    print(
        "Testing %s template cache, %s byte code cache"
        % (
            "without" if env.cache is None else "with",
            "without" if env.bytecode_cache is None else "with",
        )
    )
    run_silly_benchmark("env.get_template('foo.html')", globals={"env": env})

foo.html contained the first example template from https://jinja.palletsprojects.com/en/2.11.x/templates/#synopsis.

[davidism]

I'm not sure if you saw, but there's a PR linked above your comment that addresses this.

[dsedivec]

I'm not sure if you saw, but there's a PR linked above your comment that addresses this.

I did notice that, thank you. I noticed the PR is a couple months old on an issue that's six years old, and I can't even concretely say that it will be merged, so since I didn't know how much longer this issue might be outstanding I thought my comments might help someone else passing this way.

And please don't anyone on the development team take this as a criticism—I absolutely understand how valuable developer time is, and I am very grateful for all the work that's gone into this project.

[davidism]

It will be merged, along with all the other PRs we've gotten from the MLH program over the last 3 months. There have been so many I haven't been able to get to them all yet.

[sophiebits-humu]

This issue is now closed due to #1244, but for what it's worth – the behavior after this PR is still very surprising to me as a user. The new behavior is to merge the new globals in with any globals previously passed but to retain existing globals from the cached template.

This means that data can still leak between calls to get_template (even possibly resulting in leaking data between users, depending on how jinja is used – an incredibly severe bug). It also means the semantic behavior depends on if caching is enabled, rather than caching being solely a performance optimization.

I hope this behavior can be reconsidered before final release.

[davidism]

The fact that different globals can be passed to get_template for the same template seems to be a slight oversight. The docs don't mention globals much to begin with, but they are pretty clear that the globals, both for envs and templates, shouldn't be modified by the user after a template is created. The options are:

1. Document more strongly that's it's undefined/unsafe to pass different globals to the same template.
2. Raise an error if the globals passed don't match the globals already present. This might not be feasible, and could be a very noisy breaking change if people are relying on this undefined behavior.
3. Somehow account for whatever globals are passed in the cache key. This will be difficult since dicts (and the arbitrary values they might have) are not hashable and we want to do all loading as fast as possible.

I'm inclined to go with option 1. I don't believe it's particularly common to load the same template with different globals. Flask, for example, doesn't expose the fact that templates can have distinct globals at all, and systems such as Ansible don't expose this either.

[sophiebits-humu]

If I understand correctly, the primary motivation for the cache is to avoid the cost of re-parsing the template HTML multiple times. My hope would be that Jinja could cache that parsing but return a new Template object, which should require only a single small allocation.

If Flask and Ansible don't expose the ability to pass different globals in, then they wouldn't be affected by a minor performance regression as long as the caching of templates without globals was not affected (I agree that that seems to be the more common usage pattern).

I would argue that even with a documented warning, this is a very large footgun (even if someone is not too likely to run into this, it can be an incredibly bad bug if it does crop up) and so would prefer a solution 2 or 3 – but a warning in the documentation would be still a significant improvement over the status quo.