8.0 Migration plan for frontends implementing widgets

[jasongrout]

@DonJayamanne and I were discussing in the dev meeting how frontends implementing ipywidgets support should manage the transition from ipywidgets 7 to 8.

@DonJayamanne was hoping that the 7.x javascript might be able to support the 7.x subset of widgets even with the 8.0 kernel package. He said it worked with an 8.0 beta, but not with 8.0 RC. Officially this is not currently supported, but I'm not sure what exactly the breaking change is.

Ideally a frontend would be able to load either the 7.x or 8.x javascript, whichever is required by the kernel.

Regardless, just like we have a transition guide for custom widget authors, we should have a paragraph or two in the migration guide for frontends implementing ipywidgets helping them understand how they might bridge supporting ipywidgets 7 and 8.

[jasongrout]

See also the conversation in VS Code at microsoft/vscode-jupyter#8552

[jasongrout]

Some thoughts about this:

Widget javascript that is normally bundled with the widget manager in ipywidgets 8.0 includes models from @jupyter-widgets/base (model module version 2.0.0) and @jupyter-widgets/controls (model module version 2.0.0): See the model listing at https://github.com/jupyter-widgets/ipywidgets/blob/master/packages/schema/jupyterwidgetmodels.latest.md, as compared with the core controls provided with ipywidgets 7: https://github.com/jupyter-widgets/ipywidgets/blob/7.x/packages/schema/jupyterwidgetmodels.latest.md

Ideally, there would be a single widget manager in the frontend, and that widget manager would load both the 7.x core widget model js and the 8.x core widget model js, and use whichever model js was requested by the kernel. If the single frontend widget manager implemented the interface of both the 7.x widget manager and the 8.x widget manager, I think all would be well. There were changes in the widget manager interface from 7.x to 8.x, though, so we'd need to be careful.

Another way to manage things is to somehow peek into the kernel and know from it what possible core models would be requested, then load either the 7.x widget manager and js, or the 8.x widget manager and js. For example, we could have a new widget control comm request that would reply with the version of ipywidgets, or the list of registered models, and infer from that which widget manager to load. This isn't as elegant, but it may be less prone to breaking.

[DonJayamanne]

Another way to manage things is to somehow peek into the kernel and know from it what possible core models would be

The current thinking is to do this in VS Code. Query version of ipywidgets in the kernel and load the corresponding JS bundle.

[jasongrout]

The current thinking is to do this in VS Code. Query version of ipywidgets in the kernel and load the corresponding JS bundle.

Actually, looking into it, it does seem possible that for the core widgets, we might be able to load the 8.x core widgets into a 7.x widget manager (or the 7.x core widgets into an 8.x widget manager) and have things work. It seems the core widgets do not depend on any widget manager functionality that might have been changed. The widget manager would need to understand package names and version numbers (e.g., the jupyterlab widget manager).

[jasongrout]

Actually, looking into it, it does seem possible that for the core widgets, we might be able to load the 8.x core widgets into a 7.x widget manager (or the 7.x core widgets into an 8.x widget manager)

Oh, wait, the CSS code from 7.x and 8.x will conflict, so I think that won't really work. Hooray for the global CSS namespace...

Edit: On the other hand, we could release another 7.8 that scoped its styles to its widgets with a version identifier (either another class name or a data attribute), and likewise scoped the styles for 8.x with a different version identifier.

[DonJayamanne]

we might be able to load the 8.x core widgets into a 7.x widget manager

This was what I was attempting in this issue microsoft/vscode-jupyter#8552. However that didn't work.
I found that a core widget such as the textbox doesn't work. This was because a new class was introduced in IPyWidgets 8, the class is TextStyleModel. & to get that class, we need to load the IPyWidgets 8.0 classes (widget bundles).

[jasongrout]

To be clear, I'm imagining an AMD module that exports the 8.0 core controls, and another AMD module that exports the 7.0 core controls. Both are loaded and registered with the corresponding version number (using something like the semvercache in the jlab widget manager, or perhaps using different requirejs paths). If the kernel asks for a 8.0 text box, the 8.0 model is instantiated, and if it asks for a 7.0 textbox, the 7.0 model is instantiated.

[bollwyvl]

I was having looking at this for some generated code, and stumbled on the @jupyter-widgets/schema. Is it in fact the case that it doesn't actually contain any JSON schema for the core models/views?

There is some custom format, and the generated markdown has almost enough content. I guess folk have built things directly on those formats? I, too, had already been doing some of my own stuff, but a having real, NIH schema syntax (rather than JSON-schema-like) would help in these cases...

[jasongrout]

There is some custom format, and the generated markdown has almost enough content. I guess folk have built things directly on those formats? I, too, had already been doing some of my own stuff, but a having real, NIH schema syntax (rather than JSON-schema-like) would help in these cases...

+1 to having a real json schema spec, rather than markdown or custom JSON spec.

[jasongrout]

In #3524, we did some experiments and concluded that we have several options moving forward, and we'll wait until after the 8.0 release to see how much effort we should put into any of these options (if any), based on community input. So I'll close this issue for now.