Building the docmentation generates hundreds of warnings. Most of these seem to be the same few warnings, caused by a handful invalid "any" references in pyglet, repeated over and over for basically every class in glooey (because I have :inherited-members: enabled).
I'm not sure how to deal with this. I don't want to leave out inherited members, because then it makes it hard to cross-reference methods like Widget.push_handlers() (which is actually defined in pyglet). Also, autoclasstoc/autosummary doesn't seem to be able to cross-reference inherted members without the :inherited-members:, although maybe I can fix that somehow.
I can't think of a way to ignore warnings that are fundamentally caused by pyglet. Perhaps in some sense this is a reason not to use :any: roles (i.e. other projects might not use them in the same way, which might cause incompatibilities). But :meth: and friends are much more verbose (they seem to require fully qualified names) and they don't give errors for missing references, so I don't really think they are a viable alternative.
I could probably special-case the problematic cases (EVENT_HANDLED, EVENT_UNHANDLED, name, handler, etc.) in my "smart xref" role, but it's not a good solution.
Building the docmentation generates hundreds of warnings. Most of these seem to be the same few warnings, caused by a handful invalid "any" references in pyglet, repeated over and over for basically every class in glooey (because I have
:inherited-members:
enabled).I'm not sure how to deal with this. I don't want to leave out inherited members, because then it makes it hard to cross-reference methods like
Widget.push_handlers()
(which is actually defined in pyglet). Also,autoclasstoc
/autosummary
doesn't seem to be able to cross-reference inherted members without the:inherited-members:
, although maybe I can fix that somehow.I can't think of a way to ignore warnings that are fundamentally caused by pyglet. Perhaps in some sense this is a reason not to use
:any:
roles (i.e. other projects might not use them in the same way, which might cause incompatibilities). But:meth:
and friends are much more verbose (they seem to require fully qualified names) and they don't give errors for missing references, so I don't really think they are a viable alternative.I could probably special-case the problematic cases (EVENT_HANDLED, EVENT_UNHANDLED, name, handler, etc.) in my "smart xref" role, but it's not a good solution.