[Lab v3] No provider for: jupyter.extensions.jupyterWidgetRegistry

JupyterLab
#1

Hello. When I’m building jlab v3 locally with ipyleaflet==0.13.6 installed it works fine. But when I’m building it on my server machine(docker image jupyter/base-notebook:notebook-6.2.0), I’m getting this error:

Plugin 'jupyter.extensions.jupyter-leaflet' failed to activate. index.es6.js:283 Error: No provider for: jupyter.extensions.jupyterWidgetRegistry. at H.e.resolveRequiredService (VM4234 jlab_core.827d543b8d221fe1180d.js:2) at VM4234 jlab_core.827d543b8d221fe1180d.js:2 at Array.map (<anonymous>) at H.e.activatePlugin (VM4234 jlab_core.827d543b8d221fe1180d.js:2) at VM4234 jlab_core.827d543b8d221fe1180d.js:2 at Array.map (<anonymous>) at H.e.start (VM4234 jlab_core.827d543b8d221fe1180d.js:2) at U (index.out.js:707)

Can someone please provide me with information on what can possibly cause that problem in my situation? Is this packages incompatibility issue? So why then locally everything works like a charm?

`Error: No provider for: jupyter.extensions.jupyterWidgetRegistry` after locally installing a custom labextension
2021: The Year in Review
#2

That indicates that the Jupyter widgets extension is not installed. Assuming your server is running jlab 3, it can be installed by installing ipywidgets 7.6+ or by installing jupyterlab_widgets 1.0+.

#3

Sorry that I didn’t mention it, but I have both of them installed on my server.

#4

I’ve also been running into this issue, with the ipyevents and pywwt extensions. Like @lodka I’ve got sufficiently new ipywidgets and jupyterlab_widgets installed, as well as the @jupyter-widgets/jupyterlab-manager (v3.0.0) extension installed.

What’s frustrating is that I’ve probably solved this problem two or three times in different installations, but I keep on losing track of what I did to get things working. I’m mainly posting to remind myself to actually write the answer down here if/when I figure it out again …

edit Apologies for starting to turn this into a GitHub thread, but in the spirit of writing down my findings … Looks like we have different values for what should be the same token? Debugging Application.resolveRequiredService in my browser:

>>> token
<<< Object { name: "jupyter.extensions.jupyterWidgetRegistry", _tokenStructuralPropertyT: null }

>>> let keys = Array.from(this._serviceMap.keys());
>>> keys[53]
<<< Object { name: "jupyter.extensions.jupyterWidgetRegistry", _tokenStructuralPropertyT: null }

>>> this._serviceMap[token]
<<< undefined

So, the ipyevents plugin has a token that’s supposed to correspond to the widgets service, and the Lumino Application has a token corresponding to the widgets service, but they’re not the same object.

#5

@jasongrout Ah, ipyevents might not have been updated to express compatibility with @jupyter-widgets/base 4.x. If I have some plugins that call for @jupyter-widgets/base 3.x and others that call for 4.x, might that result in the issue I documented above?

#6

@pkgw While investigating I found out that some of the packages were using Token from phosphor package, but Token in V3 was generated via lumino package. I also found the same investigation in this thread: Browser console error: "jupyter.extensions.jupyter-leaflet failed to activate" · Issue #546 · jupyter-widgets/ipyleaflet · GitHub. It seems like the process of extension activation compares links, not their values. That’s why we’re getting such errors just because of different versions of phosphor/lumino Token == different instances of the same Token. @jasongrout, Don’t you think that such behavior should be reconsidered, or it’s needed for some way of security/version consistancy?

#7

Yes, that is correct. More technically, the Jupyter widgets manager for JLab 3 provides to the system the manager tied to the token from @jupyter-widgets/base version 4. If another widget is requesting the token from base version 3, it won’t find it and complain.

#8

Phosphor vs Lumino should not be the issue here. When things are compiled for JLab, we transparently (and forcefully) substitute Lumino for Phosphor.

ipywidgets 8 will move fully to Lumino, and JLab 4 likely will not include this shim for phosphor and require libraries to fully move to Lumino.

#9

So, if I’m understanding correctly, webpack is including two different versions of @jupyter-widgets/base in the bundle that it’s creating, and that can lead to problems. Is there any workable way to make that an error at the jupyter lab build stage? I can see how it might be tricky, since you wouldn’t want to trigger an error for random UI support libraries — only packages that provide Tokens and similar shared app resources.

#10

First, a lot of this problem goes away with jlab 3 prebuilt extensions (if they are properly built), as it has built-in this mechanism of using whatever jlab base package comes with the system rather than bringing your own.

Back to the combined webpack build for source extensions: we have such a mechanism for core token packages - the notion of “resolutions” where we force everyone to use a single package. However, (IIRC) we don’t have a way right now to have one extension force this on other extensions.

#11

Looking at this documentation:

https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html#deduplication

If I’m reading correctly, it may now be possible for @jupyter-widgets/base to specify that it should be deduplicated during the build process, I think?

#12

Sort of. First, with jlab 3, we have the main build process, and then separate build processes for each prebuilt extension. I assume you are just talking about the main jlab build process (the one that builds in the source extensions). In that case, the one webpack config used is assembled from all the various source extensions it is building in, and yes, one of those extensions can say that everyone should use a specific version of @jupyter-widgets/base that will be shared among everyone in that one core build. It does not say that prebuilt extensions must use this copy of base (since they will have their own build process with their own webpack config).

The deduplication by the new shared config is more of a cooperative deduplication than a forced deduplication for prebuilt extensions, in that prebuilt extensions must opt into it (and we provide some sensible defaults, like automatically opting into deduplicating core packages, etc.)