A more sphinx-y behavior of OutputBundleNode

[akhmerov]

Problem statement

1. Sphinx has a lot of machinery in place to process its data (collecting equation references, copying images, etc).
2. Jupyter creates output bundles that represent "data to be shown given the abilities of the renderer"
3. Because the builder is only know after the data processing has happened, we (well not jupyter-sphinx right now, but myst-nb) are now moving most processing to the post-transform stage, which might subtly break things and also introduces annoying and fragile code duplication.

Idea

Could we teach the OutputBundleNode play nicely with all other sphinx resources? For that we'd need it to pretend being math when it contains math, pretend being an image when it contains an image, etc. As far as I can tell, most of sphinx machinery relies on Node.traverse behavior, which in turn walks the ast and calls isinstance a bunch of times. That seems to suggest that implementing OutputBundleNode.__subclasscheck__ would allow to move in that direction.

WDYT?

[chrisjsewell]

As I've mentioned previously, it mainly comes down to the trade-off with storing builder agnostic data in the doctree (i.e. before post-transforms), otherwise it breaks multi builder runs (e.g. building HTML and LaTeX).
I'm open to suggestions, but its tricky to know if its math, image etc until you have processed it, currently in a build specific manner.
It would certainly be nice to have the best of both worlds.

[akhmerov]

Sphinx already has machinery for storing builder-agnostic data in the doctree, realized via node visit and leave hooks.

We could shove builder-specific logic into those hooks of OutputBundleNode rather than making it a dummy container and relying on the children's logic.

[chrisjsewell]

highly sceptical, but happy for you to write a proof-of-concept