`sphinx.ext.autosummary` does not process a subpackage, even though it imports without errors about sphinx HOT 5 OPEN

I can't understand from the description and screenshots what the problem is. Aren't libretro.api and libretro.driver on the same level of depth and aren't both being included in the toctree? Within that structure what exactly is missing?

Do you mean that you were to have 2 children (libretro.api and libretro.driver) within the top level package libretro and the subpackages are being listed with incorrect nestings and levels of depth? What seems to be happening is that you have docs for individual modules at the same level as docs for packages. There's nothing wrong with that. You also make extensive use of __all__ but in the base package's __init__.py you only include the subpackages not the modules inside the top-level package. I'm unsure how autosummary would behave in that case.

from sphinx.

I can't understand from the description and screenshots what the problem is. Aren't libretro.api and libretro.driver on the same level of depth and aren't both being included in the toctree?

Yes, that's correct.

Within that structure what exactly is missing?

libretro.driver should have doc pages for the submodules that it contains. It doesn't; they're not even generated.

Do you mean that you were to have 2 children (libretro.api and libretro.driver) within the top level package libretro and the subpackages are being listed with incorrect nestings and levels of depth?

No, libretro.driver is the only offender. All other packages are correctly nested (e.g. libretro.core is a single module not nested in api or driver).

What seems to be happening is that you have docs for individual modules at the same level as docs for packages. There's nothing wrong with that.

I agree, that's not the issue I'm facing.

You also make extensive use of __all__ but in the base package's __init__.py you only include the subpackages not the modules inside the top-level package.

You mean this base package? I'm not sure what you mean here, could you elaborate?

from sphinx.

I don't believe this...renaming the offending package from libretro.driver to libretro.impl works around the issue!

Is the string driver special at all?

from sphinx.

Using the name libretro.drivers also works as expected.

from sphinx.

@thegamecracks was looking into this and offered this insight:

from sphinx.