Skip to content
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

Open
pfebrer opened this issue Oct 10, 2024 · 3 comments
Open

sphinx.ext.autosummary: more customization options. #13003

pfebrer opened this issue Oct 10, 2024 · 3 comments
Labels

Comments

@pfebrer
Copy link

pfebrer commented Oct 10, 2024

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:

  1. Class templating does not provide enough flexibility for us.
  2. We would like to be able to tweak the display name of the class methods in the tables. For a function module.submodule.func we would like to display it as submodule.func, but the current functionality only allows func or module.submodule.func.

For each of the problems, I would like to propose a new entry point for users to customize the behavior:

  1. Depending on the class, we want to show slightly different documentation. The namespace made available to the template by default however does not allow us to customize the documentation easily inside the template. We have to either design some complex logic inside the jinja template (which looks horrible) or set the global context with the configuration 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.
  2. A config variable to post-process display names in the 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!

@zerothi
Copy link

zerothi commented Oct 11, 2024

To expand on this, the extension [sphinx-autosummary-accesors'](https://github.com/xarray-contrib/sphinx-autosummary-accessors/tree/stable) is used by other major packages, here pandasandxarray`.

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 attribute.

However, in the general case it would be nice to do:

(Class.method).attribute
(a.b.c).d.e

to deterministic show only attribute and d.e.
The exact invocation can be fine tuned. A single delimiter could also be used:

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.

@asmeurer
Copy link
Contributor

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 sympy.sin. The fully qualified name like sympy.functions.elementary.trigonometric.sin should be an implementation detail. This is particularly a problem with autosummary since the name becomes part of the URL, and we definitely don't want moving a function around in the source tree to break existing docs URLs. (see sympy/sympy#22105 and sympy/sympy#22589).

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)).

@zerothi
Copy link

zerothi commented Oct 25, 2024

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:

sub.func1
sub.func2

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

No branches or pull requests

4 participants