Configuring Jinja2 extensions

[miracle2k]

Jinja2 has this idea that when extensions need configuration, it should be done by setting attributes on the environment. It seems to be that this is currently pretty hard - I am doing this now:

from jinja2 import Environment as Jinja2Environment
class ConfiguredJinja2Environment(Jinja2Environment):
    def __init__(self, *a, **kw):
        Jinja2Environment.__init__(self, *a, **kw)
        from django_assets.env import get_env
        self.assets_environment =   get_env()

TEMPLATES = [
{
    "BACKEND": "django_jinja.backend.Jinja2",
    "OPTIONS": {
        "environment": 'myproject.settings.ConfiguredJinja2Environment',

[niwinz]

I'm not pretty sure that this approach is really good idea, independently of how jinja2 convention is :S

In my opinion, the extesion should be isolated and self-sufficient.

Use environment for set some params that some extensions may use, seems like a very bas approach. I'm missing something?

[miracle2k]

http://jinja.pocoo.org/docs/dev/extensions/#jinja2.ext.Extension

As extensions are created by the environment they cannot accept any arguments for configuration. One may want to work around that by using a factory function, but that is not possible as extensions are identified by their import name. The correct way to configure the extension is storing the configuration values on the environment.

So there really isn't any other way, and some extensions will need configuration. See also for example the fragment extension example in the Jinja2 docs.

[niwinz]

I understand... I will think something for solve it.

[niwinz]

I think that an other solution for this is some kind of hook, that will be called when all environment is up and running, that hook will receive the environment. This will decouple a little bit the environent from the configurations of third party extensions.

That do you think?

[miracle2k]

I like the idea. I don't necessarily buy the decoupling argument, but since Jinja doesn't have an API for this and you are essentially just making arbitrary modifications of the environment object, it seems just as well that the user should do this in code, not via some interface.

[wizpig64]

closing this as it's 7 years old.