The fallback mechanism is sometimes confusing when overriding templates and using a theme different than the fallback one. For example if one uses the nature theme, they have to use nature in the path of custom templates, instead of material, even if the nature theme doesn't even exist in mkdocstrings-python's sources.
It might be even more confusing with the extended templates feature recently introduced by mkdocstrings (which by itself could be a mistake too :see_no_evil:).
What I suggest for mkdocstrings, or mkdocstrings-python at least in the short term, is that we stop relying on the fallback mechanism, and either entirely support a theme, or not at all, whether directly in mkdocstrings-python's sources, or in external packages. I'm not sure yet how we would handle dependencies then: mkdocstrings, mkdocstrings-python, mkdocstrings-python-material...
The fallback mechanism is sometimes confusing when overriding templates and using a theme different than the fallback one. For example if one uses the
naturetheme, they have to usenaturein the path of custom templates, instead ofmaterial, even if thenaturetheme doesn't even exist in mkdocstrings-python's sources.It might be even more confusing with the extended templates feature recently introduced by mkdocstrings (which by itself could be a mistake too :see_no_evil:).
Also, MkDocs wants to create a new default theme, as well as moving the classic and readthedocs theme out of core, see https://github.com/mkdocs/mkdocs/issues/3636.
What I suggest for mkdocstrings, or mkdocstrings-python at least in the short term, is that we stop relying on the fallback mechanism, and either entirely support a theme, or not at all, whether directly in mkdocstrings-python's sources, or in external packages. I'm not sure yet how we would handle dependencies then:
mkdocstrings,mkdocstrings-python,mkdocstrings-python-material...