You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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?
In my local
python/module.rst
I only need to override one block of the default template.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.and then make the child template
That however fails since jinja's
FileSystemLoader
(orEnvironment
?) 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.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 useMyLoader
.This "works" as in I get no error.
Problem is AFAICT my custom
get_source
is only called once. Forindex.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.
The text was updated successfully, but these errors were encountered: