Render module member summary if member docs are on different pages

[mbraakhekke]

I have a module with a bunch of classes. I would like to have a separate page for each class with the respective docs. Additionally, I'd like to have a overview page for the module with a summary of the classes. I can generate the ref pages with a script. However, I can't get mkdocstrings to generate a summary for the module overview page. Below the ref .md. file for the module. I have to set members: false to prevent rendering the classes on the overview page. However, then the summary also doesn't get rendered. Is there a solution for this?

::: my_package.my_module options: members: false summary: true 

[pawamoy]

There's no solution yet, and that's something that bothers me too. The summary features is currently based on selected members (members, filters options, etc.), but ideally it would have two additional modes:

• summarize all public members of the root object
• summarize explicitly specified members (without rendering the members themselves)

Something like:

::: path.to.object options: summary: public # or with each kind # attributes: public # functions: public # classes: public # modules: public

(maybe it should then use selected as value instead of true for the current behavior)

::: path.to.object options: summary: - member1 - member2 - ...

[mbraakhekke]

Thanks. I assume there's no workaround (other than manually creating a table)?

The feature you proposed sounds great! To me it seems most elegant if the summary block inherits it options from the parent, unless they are manually overridden.
So this would render both the documentation of member1 and member2 and add it to the summary block:

::: path.to.object options: members: - member1 - member2 summary: true 

And this would only add member1 and member2 to the summary but not render their documentation:

::: path.to.object options: members: false summary: - member1 - member2 

This seems to match with your second proposed syntax, but I'm not sure.
I could imagine that in the future other options are added to the summary block by inheriting them from the parent, e.g. filters, members_order, etc. Of course, I can't say if this idea works with the implementation under the hood.

[pawamoy]

Alright, I created #226 to keep track of the feature request 🙂