-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
sphinx.ext.autosummary: more customization options. #13003
Comments
To expand on this, the extension [ The idea would be to allow one to fully customize where the shortening is done: I.e. right now there is only two options: ~Class.method.attribute
Class.method.attribute where the first renders only However, in the general case it would be nice to do: (Class.method).attribute
(a.b.c).d.e to deterministic show only Class.method|attribute
a.b.c|d.e or similar. Quite often would it be useful to document certain things that are tied to a method, or attribute. Especially when dealing with developer documentation where hidden attributes on methods etc. are located. |
The inability to change a reference from a fully qualified one is also a major issue for us in SymPy. In SymPy, we want users to access most function names from the top-level, like There have been a lot of other issues with autosummary (another one I've been following is #7912). I looked into this in more detail a few years ago, and discovered that the biggest issue with autosummary is that it does not actually use the mechanisms of autodoc, but rather reinvents them in a way that isn't fully compatible. My personal opinion is that autosummary should be completely rewritten to handle this better. However, one of the biggest challenges with autosummary and similar systems is that Sphinx has a fundamental design where "documents" have to correspond to "source files". What this means is that it's difficult for something like autosummary, which wants to make a different document for every function, to function in build. Instead, it has to basically write out all the files as a pre-processing step, which limits what it is able to do (see the discussion here Chilipp/autodocsumm#66 (comment)). |
For completeness @pfebrer managed to create a very minimal change that enables the above. from sphinx.ext.autosummary import Autosummary
class RemovePrefixAutosummary(Autosummary):
"""Wrapper around the autosummary directive to allow for custom display names.
Adds a new option `:removeprefix:` which removes a prefix from the display names.
"""
option_spec = {**Autosummary.option_spec, "removeprefix": directives.unchanged}
def get_items(self, *args, **kwargs):
items = super().get_items(*args, **kwargs)
remove_prefix = self.options.get("removeprefix")
if remove_prefix is not None:
items = [(item[0].removeprefix(remove_prefix), *item[1:]) for item in items]
return items
def setup(app):
app.add_directive("autosummary", RemovePrefixAutosummary, override=True) This will enable one to do (in a jinja template, or wherever): .. autosummary::
:removeprefix: package.2nd.
package.2nd.sub.func1
package.2nd.sub.func2 which results in the documentation having correct links but showing:
|
We are using
autosummary
to document our package, and we are feeling limited by the customization options currently available. In particular, we are seeing that:module.submodule.func
we would like to display it assubmodule.func
, but the current functionality only allowsfunc
ormodule.submodule.func
.For each of the problems, I would like to propose a new entry point for users to customize the behavior:
autosummary_context
and then query the context for the particular class. It would be very nice if there is a config variable to generate a per-object context. I mean, a function that receives the python object and returns the context that should be made available in the template for that particular object.Autosummary
directive would be very nice.I think both suggestions I could easily implement them myself and submit a PR, but I would like to understand if this additions would be welcome. It's my first time trying to contribute to
sphinx
so I don't have a sense for how open to changes things are in the package :)Thanks!
The text was updated successfully, but these errors were encountered: