Conversation
|
The current proposed solution looks extremely flakey. This is a super common Python idiom, surely there's a better workaround? |
I am completely aware it is flakey. i was first looking into ignoring these warnings all together. But it doesn't look like these warnings can be suppressed. As i checked the suppressing code during generation and this specific warning does not have an associated type and his warning does not have an associated type or subtype. Both of these are Even then, the other solution would be the alternative I described above, or not treating warnings as errors for the readthedocs build, and see whether we can send in a patch to sphinx to make it possible to suppress these warnings. |
There is an issue with sphinx generating warnings due to duplicate object entries
From what I found out, it only occurs in dissect-docs, this is not an issue when using docs-build
in other projects.
What I think the issue might be is that this issue occurs due to shadowing of modules, and sphinx not knowing how or what.
For example, with the following construction:
Sphinx sees both
dissect.cstruct.__init__.cstructanddissect.cstruct.cstructas conflicting/duplicate object entries.I assume this happens because the one in the
__init__.pyfile shadows the modulecstructin the same directory.My current fix is skip generating rst for the cstruct class inside
api/dissect/cstruct/indexand only render it inapi/dissect/cstruct/cstruct/index.An alternative method is avoid generating class definitions exposed by
__init__.__all__at all insideapi/dissect/cstruct/indexthis would remove all those classes belowFunctions.