readthedocs / sphinx-autoapi

A new approach to API documentation in Sphinx.
https://sphinx-autoapi.readthedocs.io/
MIT License
415 stars 127 forks source link

Extendable templates? #288

Open renefritze opened 3 years ago

renefritze commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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?