Support for _repr_mimebundle_

[SylvainCorlay]

The Jupyter Python kernel now supports a new repr function called _repr_mimebundle_ which can be used to provide several representations of the same object in a dictionary. Unlike _repr_[html|json|svg|png...]_ which are only a limited list of supported mimetypes.

As an increasing number of packages use _repr_mimebundle_ it may be interesting for sphinx-gallery to support it.

We could start with checking if the mimebundle includes a text/html entry and use that in the same way as _repr_html_ is used...

Note: jupyter-sphinx's support of _repr_mimebundle_ was already mentioned here and here.

[GaelVaroquaux]

This seems like a low-hanging fruits with multiple benefits (including for scikit-learn). @lucyleeow , can you look at this please! Thanks!

[choldgraf]

+1 from me as well, I am a big fan of supporting community standards.

@SylvainCorlay I assume you mean sphinx-gallery instead of jupyter-sphinx?

[SylvainCorlay]

@choldgraf yes. Sorry - this is fixed. I work with too many projects.

[choldgraf]

you and me both :-)

[lucyleeow]

@GaelVaroquaux @SylvainCorlay what's a good example of an object with a _repr_mimebundle_ that I can play with and use in a test?

[lucyleeow]

Or should I create my own dummy class?

[SylvainCorlay]

Hey @lucyleeow, pardon my brevity as I am responding from my phone.

I included a couple of screenshots of usage in the linked scikit-learn issue!

Thanks!

[SylvainCorlay]

[GaelVaroquaux]

I guess an important question for us, in sphinx-gallery is: which major object uses repr_mimebundle ?

I had a quick look and it seems that my typical goto object, the pandas DataFrame, does not implement it in version 1 of pandas.

[lucyleeow]

I can make a dummy object and use that in the test if there is no 'major object'.

[SylvainCorlay]

@GaelVaroquaux IPython uses it, and also all projects that require custom mime types use it (ipywidgets, altair).

[emmanuelle]

and we should probably use it for plotly, so I'm also interested :-). Thanks for raising this @SylvainCorlay

[GaelVaroquaux]

An example with altair would be great!! I'd be so excited to have an example in sphinx-gallery that uses altair.

[SylvainCorlay]

I'd be so excited to have an example in sphinx-gallery that uses altair.

Then that will be a bit more work to than just supporting the text/html mime type in _repr_mimebundle_.

[SylvainCorlay]

@GaelVaroquaux should I open a separate (and more general) issue on using the kernel protocol and Jupyter's display system like in jupyter-sphinx to support bokeh, widgets, altair, etc?

[GaelVaroquaux]

OK, I thought that Altair was javascript only, like plotly :(. I don't really see how we could support something that needs a jupyter kernel. It's too heavy for what we do. Plotly, on the other hand is easy because it is javascript only.

[SylvainCorlay]

I don't really see how we could support something that needs a jupyter
kernel. It's too heavy for what we do. Plotly, on the other hand is easy
because it is javascript only.

I don't think you understand what I mean. All these examples are javascript only. The kernel is only used at build time of the doc.

[SylvainCorlay]

Would you like to discuss this real quick - to be on the same page with respect to understanding each other.

[GaelVaroquaux]

Having everything depend on the kernel is a problem. For instance, you want to install a new version of a package, and as a consequence it needs an update of the kernel, which ends up updating the frontend, then plotly, then pandas, and you're left with a broken jupyterhub (unlikely but did happen to me last week) or broken data-analysis scripts because pandas has details that change from a version to another. It is crucial to avoid long dependence chains. They entail major operational risks in projects.

[SylvainCorlay]

@GaelVaroquaux would you like to chat?

[SylvainCorlay]

Having everything depend on the kernel is a problem. For instance, you
want to install a new version of a package, and as a consequence it needs
an update of the kernel, which ends up updating the frontend, then
plotly, then pandas, and you're left with a broken jupyterhub (unlikely
but did happen to me last week) or broken data-analysis scripts because
pandas has details that change from a version to another.

Installing a kernel does not update the front-end. This is a weird statement...

[choldgraf]

I think one challenge for this is supporting the many different kind of mimetypes that can exist in a mimebundle. Some of the libraries don't just use regular text/html mimetypes, they register their own (e.g. I believe the ipywidgets do this). So we'd have to make clear that we only support some subset of mimetypes so users know what to expect

Could get around this by using the IPython display function to display the mimebundle? e.g., that's what scrapbook does here: https://github.com/nteract/scrapbook/blob/master/scrapbook/api.py#L97