Widgets 7 in JupyterLab 2.0

[jasongrout]

I think we can get ipywidgets 7 to work for JupyterLab 2.0. It will require custom widget authors to update their code to for jlab 2 just like we had them update for jlab 1. See https://ipywidgets.readthedocs.io/en/stable/changelog.html#updates-for-widget-maintainers (they'll need to require @jupyter-widgets/base version ^1.1 || ^2 || ^3 now). This works if the custom widgets do not pull in phosphor or jlab packages, but I think most custom widgets don't do either.

This will give some people time to migrate from widgets 7 to widgets 8, and then I think we can say JLab 3 supports just widgets 8.

[jasongrout]

I branched off a widgets 7.x branch just before we merged the PR dropping python 2. This PR is then for updated the 7.x branch to work on JupyterLab 2.0. I think we don't even need to release a new version of ipywidgets, since we don't really change any python files since ipywidgets 7.5, but I suppose we can release ipywidgets 7.6 if it makes the communication clearer. We just need to release new major versions of the base, controls, and other js packages, as well as widgetsnbextension.

[jasongrout]

CC @jupyter-widgets/jupyter-widgets - thoughts? You can try out this PR in JupyterLab 2.0rc0, for example.

[jasongrout]

Actually, there are no changes inside the ipywidgets directory since 7.5.1 with this PR, which indicates that we do not need to release python packages, just the js packages and widgetsnbextension.

[jasongrout]

And actually, I think we probably don't even need to release widgetsnbextension? Perhaps we just release new major versions of the published npm packages.

[mwcraig]

This seems like a good idea; won't be able to kick the tires until the weekend, at earliest.

[jasongrout]

Sounds good. Any objection from anyone about me releasing an RC for the public npm packages Thursday or Friday so it is easier for people to test with jlab 2.0rc? That will also make it easier for us to test what changes are needed for custom widgets to be supported in jlab 2.0 without having to move to ipywidgets 8.

[jasongrout]

Looks like the one failure is the arm test: "ERROR: Could not build wheels for cryptography which use PEP 517 and cannot be installed directly" - which looks like it is unrelated. I'll disable the arm test for now, since it seems like it isn't adding anything, and these packages are pure python, so it's not clear what we gain anyway by testing on arm.

[vidartf]

Looks good on a first browse of the source. Thanks! I can do a review of the widget libraries that I work on for any that interact more closely with the comms, and test those once an RC is out.

[jasongrout]

Merging so I can make a prerelease of the js packages.

[jasongrout]

Okay, I published prerelease versions of:

• @jupyter-widgets/base@3.0.0-rc.0
• @jupyter-widgets/controls@2.0.0-rc.11
• @jupyter-widgets/html-manager@0.19.0-rc.2
• @jupyter-widgets/jupyterlab-manager@2.0.0-rc.2
• @jupyter-widgets/output@3.0.0-rc.0

[jasongrout]

I tested with bqplot, and things seem to work (except that bqplot actually imports from phosphor for one small thing, so I had to comment that out to test, and I had to explicitly depend on the prerelease packages above since the || prefers an actual release).

If others (@vidartf, @martinRenou @maartenbreddels ) want to test, that would be great. You'll need to:

• update your @jupyter-widgets/base dependency to @jupyter-widgets/base@3.0.0-rc.0,
• make sure your package does not import phosphor
• install the prerelease of jlab, 2.0.0rc0
• jupyter labextension install @jupyter-widgets/jupyterlab-manager@next
• install your package from your js package source directory

If at least one more person can confirm it works, I'll consider this good for releasing in conjunction with jlab, probably next Wednesday.

[maartenbreddels]

Yes, plan to take a look at this soon. Any advice for packages that did use phosphor, like ipyvue/ipyvuetify (cc @mariobuikhuizen)? e.g.
https://github.com/mariobuikhuizen/ipyvue/blob/master/js/src/VueRenderer.js#L13

[jasongrout]

Yes, plan to take a look at this soon. Any advice for packages that did use phosphor, like ipyvue/ipyvuetify (cc @mariobuikhuizen)? e.g.

Yeah, that's going to a be a problem to support both jlab 1.0 and jlab 2.0. You need to migrate from phosphor to lumino in jlab 2.0.

There are maybe some tricks you can play with the package.json browser field (see https://github.com/defunctzombie/package-browser-field-spec), but I think that would make it not work on jlab 1.0, so it's not better than just releasing a jlab 2.0-specific release.

If you are using phosphor and can't get away from it, I think you'll need to make a JupyterLab 2.0-specific release. Ugh, that means that if you want that same package to work in classic, we'd need to release a new widgetsnbextension that uses Lumino, I think. But since ipywidgets depends on widgetsnbextension, that means a new major version of ipywidgets. Or perhaps we make a minor ipywidgets release that depends on current widgetsnbextension or the next major release. Then you have to communicate with users that if you are using ipyvue version X, then you have to upgrade to the latest ipywidgets 7.6, and make sure to install widgetsnbextension 4. Ugh, this is a mess.

The alternative would be to quickly have jlab 2.0 use its webpack resolutions module to automatically convert phosphor references to lumino references. That would mean extensions could keep using phosphor (which would transparently get migrated to Lumino references). We may not want to do that indefinitely, as we do want people to migrate to Lumino, but perhaps that's enough of a bridge to have jlab 2.0 do the automatic conversion and jlab 3.0 officially drop phosphor. By jlab 3.0, we'll have ipywidgets 8, which involves a major release of all the widget packages anyway.

I'm going to raise this on the jlab repo.

[maartenbreddels]

Can't we export something from ipywidgets, or via the widgetmanager get a reference to JupyterPhosphorWidget or the Lumino equivalent class?

[jasongrout]

Oh wait, you don't require phosphor. You just require the JupyterPhosphorWidget, which is still being exported unchanged from the widgets base package, so you should be good!

[jasongrout]

(Just in the new base package, it actually imports Lumino rather than Phosphor)

[jasongrout]

I'm going to raise this on the jlab repo.

Since I think things will actually work for ipyvue, I'll hold off on raising the issue in jlab. Especially since I think it will be easy in jlab to issue a minor or patch release re-enabling phosphor (by aliasing it to lumino) if it becomes a huge issue. We'll have to figure out what to do for bqplot, though, which actually does import phosphor.

[jasongrout]

Can't we export something from ipywidgets

Just to be clear, that is exactly what we do already - you're getting JupyterPhosphorWidget from the widgets base class.

[SylvainCorlay]

I am not sure this will really be backward compatible though.

[jasongrout]

I am not sure this will really be backward compatible though.

Not sure what you mean. Can you elaborate?

[SylvainCorlay]

Any custom widgey that refers diectly to phosphor will end up with both lumino and phosphor objects.

[jasongrout]

Any custom widgey that refers diectly to phosphor will end up with both lumino and phosphor objects.

See the long discussion over on jupyterlab/jupyterlab#7230 about that. For many widgets, though, I think it will work just fine, since most custom widgets don't import phosphor directly, at least the ones I checked.

[vidartf]

A pertinent question: Will a phosphor Application accept a lumino Token, and vice-versa?

[jasongrout]

@blink1073 put in a PR (jupyterlab/jupyterlab#7893) that adds the aliases to JupyterLab. We can test it by hand-modifying the JLab webpack config appropriately and seeing if a custom widget package works.

The token issue is a really good question. I think the webpack aliases will make that work, but I'm not sure if Typescript will complain.

[jasongrout]

@meeseeksdev please backport to master

[jasongrout]

@meeseeksdev hello

[jasongrout]

@meeseeksdev hello

[jasongrout]

@meeseeksdev please backport to master