Closed zaneselvans closed 1 week ago
I just ran across this same issue when my builds started failing on readthedocs.io. I've pinned the sphinx-autoapi version for now, as mentioned by @zaneselvans, but it would be nice to not have to do that.
If a test case is needed, my project is here: https://github.com/mfncooper/pyham_pe (but to reproduce the error, remember to unpin sphinx-autoapi in requirements-docs.txt before building the docs).
As documented here (https://sphinx-autoapi.readthedocs.io/en/latest/how_to.html#how-to-customise-what-gets-documented), this is the correct behaviour:
AutoAPI will document everything that is publicly accessible through the actual package when loaded in Python. For example if a function is imported from a submodule into a package then that function is documented in both the submodule and the package.
That section describes how to control what's documented. Or you could change the xref
to use the full path to the class.
My situation is the opposite of what you're pointing out, though. I have module A that defines class C. Then I have submodule B that imports class C. Why would it be "correct" for the importing module - module B - to document the class it's importing from module A?
Specifically, my top level module defines the class ReceiveHandler: https://github.com/mfncooper/pyham_pe/blob/main/pe/__init__.py#L48
and a submodule imports that class: https://github.com/mfncooper/pyham_pe/blob/main/pe/handler.py#L17
so that it can use it as a base class: https://github.com/mfncooper/pyham_pe/blob/main/pe/handler.py#L23
It makes no sense for the documentation for the handler
submodule to duplicate the documentation for the ReceiveHandler
class that's defined in the parent module.
I didn't realise that was the situation. You're right that a module that's importing from another module shouldn't be documenting the class, so this sounds like a regression.
Since AutoAPI 3.1.0 I have started getting a warning about multiple targets for a cross-reference, in which one is the definition of a class, and the other is that class being imported in another module. E.g. in this CI run.
See this comment
Forcing the environment to use
sphinx-autoapi>=3,<3.1
avoids the problem, but it seems like it shouldn't be an issue in either version.