Installing the ipywidgets for jupyterlab breaks

[AbdealiLoKo]

We are using ipywidgets 7.0.0 in our systems and are using jupyter-widgets/jupyterlab-manager v0.27.0 with jupyterlab 0.27.0

It looks like there was a jupyter-widgets/base v1.1.8 which is incompatible with these but the previous jupyer-widgets/jupyterlab-manager is using ^1.0.1 implying any system which is trying to use jupyter-widgets/jupyterlab-manager will now build with jupyter-widgets/base v1.1.8 and will be broken.

Seems to us like the jupyter-widgets/base which seems to be backward incompatible has been released as a 1.x series and braking other packages - as this is backward incompatible, it should have been a 2.x series ?

[jasongrout]

Do you happen to know what the incompatibility was?

[AbdealiLoKo]

Some issue with the model. Not sure on what specifically it was.

https://github.com/jupyter-widgets/ipywidgets/blob/master/packages/base/src/manager-base.ts#L347

"Could not instantiate widget" is the error I get.

Note that if I update ipywidgets to 7.1.2 - it gets fixed.

The combination that worked a few months ago - ipywidgets==7.0.0 and jupyter-widgets/[email protected] doesn't seem to work now

[jasongrout]

Was there another error shown? It looks like it prints out that, and then throws the real error.

[jasongrout]

I can't even get jupyterlab 0.27 running - apparently it depends on the latest jupyterlab_launcher, which is maybe incompatible?

[AbdealiLoKo]

Hm, I'm not sure on this. We have a fairly old installation of jupyterlab from last September

@rsinha25 - any comments?

[jasongrout]

(apparently it depends on jupyterlab_launcher 0.4.0 - explicitly installing that makes jlab 0.27.0 work).

[jasongrout]

I just duplicated the error. I see:

Module @jupyter-widgets/controls, semver range 1.0.0 is not registered as a widget module

This comes because the controls package was upgraded to be protocol version 1.1.0, but the python side still is looking for just protocol version 1.0.0 (see

ipywidgets/packages/controls/src/version.ts

Line 9 in b41d4dc

const JUPYTER_CONTROLS_VERSION = '1.1.0';

).

Here are a couple of possible ways to deal with this (in a semi-technical ramble of thoughts):

1. Register the controls package as every protocol version it supports (e.g., 1.0.0, 1.1.0, etc.). Perhaps this means that the controls package maintains a list of compatible versions the widget manager uses to register. Of course, this is exactly the sort of issue semver ranges are designed to solve nicely.
2. Introduce some logic to do the automatic upgrade in the jlab manager (i.e., instead of just looking for 1.0.0 controls, always look for ^1.0.0 controls).
3. Change ipywidgets 7.0.x to look for controls with ^1.0.0 controls protocol version, and ipywidgets 7.1.x to look for ^1.1.0. I didn't like this originally, because I'd rather the protocol version specify exactly what version the python side was going to speak, rather than giving an open-ended range.
4. Make @jupyter-widgets/jupyterlab-manager depend only on patch upgrades of controls (and probably base as well) (so the protocol versions would match - but we still have problems with possible patch upgrades of the protocol version).

[AbdealiLoKo]

Ah. I do see the semver error too. I thought that was an error coming up because of a previous error and disregarded it.
Making it robust in the future would be great. Any thoughts on how I can resolve this for my current system?
I tried keeping the version of Jupyter-widget/base as 1.0.x in my own extension but it didn't work (Jupyter lab keeps two versions of the package - one for jupyterlab-manager and another for my Extension.)
Would making a dependency to /controls in my extension help?

[jasongrout]

Yes, I think it's the dependency on controls that is the solution.

[jasongrout]

Let's see if we can at least put in place a solution going forward (especially since we are going to be bumping the controls version again for 7.2).

[jasongrout]

In the current jupyterlab-manager, we take care of this issue by registering controls under both the current version and previous versions, but it's a manual process and doesn't work so well with old jupyterlab-managers.

Releasing 7.2 will run into the same issue - the current jupyterlab-manager will register control spec 1.0.0 and 1.2.0, but not 1.1.0. Perhaps we should release a patch release of jupyterlab-manager to add 1.1.0 registration, again as a stop-gap.

@SylvainCorlay - let's rehash this version stuff (yet again)...

[jasongrout]

Actually, let's continue the discussion on #2017, where I've made a change.

[AbdealiLoKo]

Wanted to understand if:

Perhaps we should release a patch release of jupyterlab-manager to add 1.1.0 registration, again as a stop-gap.

This is happening For the 1.1.0 fix too?

[jasongrout]

The version we are releasing soon (like in the next few days, hopefully, compatible with jlab 0.31, i.e., jlab beta 1) should handle 1.0.0, 1.1.0, and 1.2.0. Is that what you are wondering?

[jasongrout]

(In other words, the jlab manager we are releasing in the next few days should work with ipywidgets 7.0, 7.1 and 7.2.)

[AbdealiLoKo]

Yes. I think that would resolve it =)
I should be able to use: jupyer-widgets/jupyterlab-manager (the new release) , jupyterlab 0.27.0 and ipywidgets 7.0.0

Would I be forced to upgrade jlab from 0.27.0 to 0.31.0 ?

[jasongrout]

The new jlab-manager is only compatible with jupyterlab 0.31.x. Is it crucial to you to stay on jlab 0.27? That is quite old at this point, and both that version of jlab and that version of jlab-manager were considered alpha.

[AbdealiLoKo]

XD yeah it's required for me to continue using the alpha version for now.
But I understand that backward compatibility with those alpha versions would be very difficult to do.
I'll probably pin the version for controls somewhere.

[jasongrout]

Thanks - that's probably the easiest solution for everyone involved at this point.