Skip to content

Extendable templates? #288

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
renefritze opened this issue Apr 30, 2021 · 2 comments
Open

Extendable templates? #288

renefritze opened this issue Apr 30, 2021 · 2 comments

Comments

@renefritze
Copy link
Contributor

In my local python/module.rst I only need to override one block of the default template.

{% extends "python/module.rst" %}

{% block functions scoped %}
{% endblock %}

That fails, somewhat expectedly, with an RecursionError. My idea for a workaround was to inject a custom filter to make the path for the extend absolute.

def _autoapi_prepare_jinja_env(jinja_env):
        jinja_env.filters["base_template"] = lambda value: f'{autoapi.settings.TEMPLATE_DIR}/{value}'

autoapi_prepare_jinja_env = _autoapi_prepare_jinja_env

and then make the child template

{% extends "python/module.rst" | base_template %}

{% block functions scoped %}
{% endblock %}

That however fails since jinja's FileSystemLoader (or Environment?) always appends given paths as relative to its preset basedir(s). So then I hacked the jinja env further, including a new loader that has the filesystem root as the last search path.

autoapi_template_dir = '/my/local/template_dir'

def _autoapi_prepare_jinja_env(jinja_env):
    import jinja2
    tpl_dir = autoapi.settings.TEMPLATE_DIR
    jinja_env = jinja_env.overlay(loader=jinja2.FileSystemLoader([tpl_dir, autoapi_template_dir, '/']))
    jinja_env.filters["base_template"] = lambda value: f'{tpl_dir}/{value}'

Jinja still doesn't find the base template with the absolute path though, so I used a custom loader. Also the overlay doesn't actually use MyLoader.

autoapi_template_dir = this_dir / '_templates' / 'autoapi'

import jinja2
from os.path import join, exists, getmtime

class MyLoader(jinja2.FileSystemLoader):

    def get_source(self, environment, template):
        try:
            return super().get_source(environment, template)
        except jinja2.TemplateNotFound:
            path = template
            print(f"LOAD {template}")
            mtime = getmtime(template)
            with file(template) as f:
                source = f.read().decode('utf-8')
            return source, template, lambda: mtime == getmtime(template)

def _autoapi_prepare_jinja_env(jinja_env):
    tpl_dir = autoapi.settings.TEMPLATE_DIR
    jinja_env.filters["base_template"] = lambda value: f'{tpl_dir}/{value}'
    jinja_env.loader = MyLoader([tpl_dir, autoapi_template_dir])

This "works" as in I get no error.
Problem is AFAICT my custom get_source is only called once. For index.rst.

So bottom line I'm looking for either the problem with my workaround, or how I could generally make this workflow possible in autoapi, less hackish.

@AWhetter
Copy link
Collaborator

AWhetter commented May 9, 2021

I'm afraid that I don't have a better answer to this problem other than to override the entire template.

Exactly how templates should be overridden, if at all, needs some thought. Overriding the templates is a sticky business. We provide some configuration options to make overriding templates unnecessary for most users. So overriding templates is really only for those power users who want extra control.
The options that change output usually end up affecting an if statement in the templates. But what if we add a new configuration option and the user has overridden the templates? What if we add some new functionality that adds something new to the output? The user would miss out on this new functionality unless they edit the templates themselves.
Overriding blocks helps with this situation because users are then only overriding a small section of the template, and so the likelihood of coming across one of the above conflicts is much smaller. For that reason, I've been organising the templates into blocks. But the templates still change often enough that I'm not comfortable considering them as having a "public API" yet and that's why the structure of the blocks isn't documented yet either.

@renefritze
Copy link
Contributor Author

One of the concerns why I didn't want to override the entire template, was exactly what you mentioned. Drift from the "base".
Maybe instead of solving the entire problem right away, as a first step, we could make it easier for users overriding templates to detect drift? Can template declare a version property that is checked at load time and would produce a warning if some mismatch is detected?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants