sphinx autosummary: "failed to import Child.model" (inherited instance attribute)

[AntonioCarta]

Describe the bug

I'm having trouble with sphinx and autosummary. Apparently, sphinx is unable to document inherited instance attributes. For some reason, the resulting error is an import error.

python code:

class Base:
    """Base class."""

    def __init__(self, **kwargs):
        """Init."""
        self.model = None
        """An attribute."""


class Child(Base):
    """Child class."""

    def __init__(self, **kwargs):
        """Init."""
        super().__init__()
        pass

rst documentation file:

.. autosummary::
    :toctree: generated

    mylib.Base
    mylib.Child

when I run sphinx-build with make html I get the following error:

.../new_docs/generated/mylib.Child.rst:24: WARNING: autosummary: failed to import Child.model

Notice that everything else is imported correctly, so this is not a path issue.
Is this a bug? According to #3257 it should be supported. I'm using sphinx-build 4.3.0.

How to Reproduce

MWE to reproduce the error: sphinx-demo.zip
unzip the archive

$ cd docs
$ make html

Expected behavior

inherited instance attributes are documented correctly and without warnings.

Your project

sphinx-demo.zip

Screenshots

No response

OS

WSL 2 (Ubuntu)

Python version

3.9.7

Sphinx version

4.3.0

Sphinx extensions

sphinx.ext.autosummary

Extra tools

No response

Additional context

No response

[smarie]

Same problem here. Is this a regression ?

[melissawm]

It looks like this was supposed to be fixed by #9146, but I'm also seeing this problem. In my case, I was able to fix this using a jinja filter to simply remove the instance attributes from the docs, but it looks like a very clunky solution - and ideally those instance attributes should be documented.

[AntonioCarta]

@melissawm could you share your jinja filter? It would help as a temporary fix until this is fixed.

[janlugt]

A workaround for me was to redefine the fields in the child class. Not sure whether that's an option for you, but it gets rid of the warning, which was important for us, since we alert on that.

[jenshnielsen]

I had a look at this trying to figure out what goes wrong. As far as I can see the issue is that import_ivar_by_name only returns a result if qualname (aka. the name of the Class we are trying to document) is in the name found by ModuleAnalyzer. However for an inherited attribute the name found will be the name of the super class so nothing useful is returned an an ImportError is raised

[melissawm]

Sure @AntonioCarta here you go!

[jenshnielsen]

@AntonioCarta @janlugt @melissawm Any change that any of you could test my suggested fix in #10691 I have been using it for a while and it seems to resolve my issue

[mbraakhekke]

I have the same problem and can confirm that #10691 fixes it for me. Thanks! Hope this gets merged soon!

[taylorm0192]

@jenshnielsen Very keen to have this cut into a new version asap as well, so thank you first for making the PR and second pushing to get it tested/released! This bug spams our doc builds with all of these silly import errors because of our heavy use of derivative dataclasses.

Can affirm that copy/pasting the diff to import_ivar_by_name makes the errors go away for us too.

[leotrs]

One more for "I have this problem and #10691 is the fix". Thanks @jenshnielsen

[oselcuk-iqm]

We also have this problem and #10691 fixes it

[12rambau]

One more for "I have this problem and #10691 is the fix". Thanks @jenshnielsen