Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reset the next npm tag for @jupyterlab/rendermime-interfaces #14335

Open
jtpio opened this issue Apr 7, 2023 · 21 comments
Open

Reset the next npm tag for @jupyterlab/rendermime-interfaces #14335

jtpio opened this issue Apr 7, 2023 · 21 comments
Assignees
Milestone

Comments

@jtpio
Copy link
Member

jtpio commented Apr 7, 2023

Problem

Currently downstreams using the @jupyterlab/buildutils/lib/update-dependency.js script to update the @jupyterlab packages pull version 4.0.0-alpha.9 because it is marked as next.

However the version was unbumped to 3.8.x for JupyterLab 4: 3.8.0-beta.1 to avoid forcing mimerender extension to update their extensions for JupyterLab 4.

image

Proposed Solution

We should reset the next tag to point to the 3.8.x version so it's easier to update the packages during the beta and rc cycles.

Additional context

This usually comes up when updating Notebook 7 to the latest JupyterLab 4 pre-releases: https://github.com/jupyter/notebook

@jtpio jtpio added enhancement status:Needs Triage Applied to new issues that need triage labels Apr 7, 2023
@jtpio
Copy link
Member Author

jtpio commented Apr 7, 2023

Actually not sure if resetting the tag (for example manually) would help, or if JupyterLab will make it point to 4.0.0-alpha.9 anyway during the release process. Probably the answer is in the release scripts.

@jtpio jtpio removed the status:Needs Triage Applied to new issues that need triage label Apr 7, 2023
@jtpio jtpio added this to the 4.0.0 milestone Apr 7, 2023
@fcollonval
Copy link
Member

I fixed it manually - we should check at the next release if it is consistent or not.

@jtpio
Copy link
Member Author

jtpio commented Apr 27, 2023

Looks like it's back to pointing to 4.0.0-alpha.9:

image

Maybe we'll have to update the deploy scripts in JupyterLab to add a special case for this package.

@fcollonval
Copy link
Member

Thanks for checking out @jtpio

@jtpio
Copy link
Member Author

jtpio commented May 15, 2023

Bumping to 4.0.x to check that again after the final 4.0 release.

@jtpio jtpio modified the milestones: 4.0.0, 4.0.x May 15, 2023
@hbcarlos
Copy link
Member

Hi! I think we have a small problem with this package.

I just created an extension for jupyterlab v3 from the cookiecutter. I tried to install it before changing anything, and it failed.

yarn run v1.21.1
$ jlpm build:lib && jlpm build:labextension:dev
$ tsc --sourceMap
node_modules/@jupyterlab/rendermime/lib/widgets.d.ts:8:31 - error TS2420: Class 'RenderedCommon' incorrectly implements interface 'IRenderer'.
  The types of 'title.owner.layout' are incompatible between these types.
    Type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@lumino/widgets/types/layout").Layout | null' is not assignable to type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout | null'.
      Type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@lumino/widgets/types/layout").Layout' is not assignable to type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.
        Property '[Symbol.iterator]' is missing in type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@lumino/widgets/types/layout").Layout' but required in type 'import("/home/carlos/Documents/blockly-widgets/jupyterlab_blockly_widgets/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.

8 export declare abstract class RenderedCommon extends Widget implements IRenderMime.IRenderer {
                                ~~~~~~~~~~~~~~

  node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout.d.ts:83:14
    83     abstract [Symbol.iterator](): IterableIterator<Widget>;
                    ~~~~~~~~~~~~~~~~~
    '[Symbol.iterator]' is declared here.

The problem is that we updated the dependencies of @jupyterlab/rendermime-interfaces to lumino v2 and released it as a minor version (v3.8.0). When creating a new extension for jupyterlab v3 it installs @jupyterlab/rendermime-interfaces v3.8.0 with lumino v2.

We should bump the version of the packages to 4 or maybe allow both versions of Lumino.

@echarles
Copy link
Member

I opened #13647 some time ago for exactly this.

@jhgoebbert
Copy link

jhgoebbert commented May 19, 2023

Also @jupyterlab/docregistry version 3.x is infected by the bug - and so are many other @lumino 1.x extensions:
https://github.com/jupyterlab/jupyterlab/blob/v3.6.3/packages/docregistry/package.json#L52

@jtpio
Copy link
Member Author

jtpio commented May 22, 2023

Could switching to use the ~ specifier instead of ^ help mitigate this issue ("@jupyterlab/rendermime-interfaces": "~3.6.3") ? This would then require a new JupyterLab 3.6.x release.

@jhgoebbert
Copy link

Yes, a new JupyerLab 3.6.4 which fixes its package.json files could be a solution.
.
In the long run it would be even better if a version 4.0.0 of @jupyterlab/rendermime-interfaces would exist and 3.8.0 could be yanked. But there might be other reasons why that is no option. 🤔

@krassowski
Copy link
Member

Just FYI, 3.6.4 was released but it did not include the fix yet. THere is a PR here #14618 and would need to go in 3.6.5.

Note: this also affects CI of nbdime.

@fcollonval
Copy link
Member

4.0.2 has been released and it should fix this (rendermime-interfaces 3.8.2 supports both lumino 1.x and 2.x)

Could some of you please confirm it fixes your issue?

@jhgoebbert
Copy link

jhgoebbert commented Jun 9, 2023

I tried to build the dask-labextension https://github.com/dask/dask-labextension for JupyterLab 3.6.4 but unfortunately it still fails with

      node_modules/@jupyterlab/rendermime/lib/widgets.d.ts(8,31): error TS2420: Class 'RenderedCommon' incorrectly implements interface 'IRenderer'.
        The types of 'title.owner.layout' are incompatible between these types.
          Type 'import("/dev/shm/dask_labextension-6.1.0/node_modules/@lumino/widgets/types/layout").Layout' is not assignable to type 'import("/dev/shm/dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.
            Property '[Symbol.iterator]' is missing in type 'import("/dev/shm/dask_labextension-6.1.0/node_modules/@lumino/widgets/types/layout").Layout' but required in type 'import("/dev/shm/dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.

I double checked if rendermime-interface 3.8.2 is really used and checked /dev/shm/dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/package.json but it shows `"version": "3.8.2",´.

Two different versions of @lumino/widgets are the mismatch:

/dev/shm/dask_labextension/dask_labextension-6.1.0/node_modules/@lumino/widgets/package.json -> version 1.37.2
/dev/shm/dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/package.json -> version 2.1.1

@krassowski
Copy link
Member

It works for me; the previously failing CI build of nbdime, is now passing smoothly.

Locally a clean install after removing all node_modules (and any resolution pins for rendermime-interface package if you had any) works fine too (just upgrading rendermime-interface may not give you the right versions of other packages I think).

@jhgoebbert
Copy link

I tried to build the dask-labextension https://github.com/dask/dask-labextension for JupyterLab 3.6.5 but unfortunately it still fails

      node_modules/@jupyterlab/rendermime/lib/widgets.d.ts(8,31): error TS2420: Class 'RenderedCommon' incorrectly implements interface 'IRenderer'.
        The types of 'title.owner.layout' are incompatible between these types.
          Type 'import("dask_labextension-6.1.0/node_modules/@lumino/widgets/types/layout").Layout' is not assignable to type 'import("dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.
            Property '[Symbol.iterator]' is missing in type 'import("dask_labextension-6.1.0/node_modules/@lumino/widgets/types/layout").Layout' but required in type 'import("dask_labextension-6.1.0/node_modules/@jupyterlab/rendermime-interfaces/node_modules/@lumino/widgets/types/layout").Layout'.

@fcollonval
Copy link
Member

fcollonval commented Jun 28, 2023

@jhgoebbert I solved the issue using the following commands within a fresh environment on the main branch:

# Installation on the current working lock file
jlpm install

# Upgrade to latest 3.x packages
jlpm upgrade --caret --scope jupyterlab

# Minimize dependency versions
jlpm add -D yarn-deduplicate@^5.0.0
jlpm yarn-deduplicate -s fewer
jlpm install

# Should succeed
jlpm build

@jhgoebbert
Copy link

Thank you very much for the work-around!
.
After the first jlpm install I can see in yarn.lock the duplication of @lumino/widgets which seems to be the source of the problem:

"@lumino/widgets@^1.17.0", "@lumino/widgets@^1.37.2":
  version "1.37.2"
  resolved "https://registry.yarnpkg.com/@lumino/widgets/-/widgets-1.37.2.tgz#b408fae221ecec2f1b028607782fbe1e82588bce"
  integrity sha512-NHKu1NBDo6ETBDoNrqSkornfUCwc8EFFzw6+LWBfYVxn2PIwciq2SdiJGEyNqL+0h/A9eVKb5ui5z4cwpRekmQ==
  dependencies:
   [..]

"@lumino/widgets@^1.37.2 || ^2.1.1":
  version "2.2.0"
  resolved "https://registry.yarnpkg.com/@lumino/widgets/-/widgets-2.2.0.tgz#c949045e45d13388a1d07f2234dd96658d994d35"
  integrity sha512-nQ5UXjcl+Tvddeev0We5aoW2erm5KffKCJZEo6/1i4t2cj90v2ndqtXtbiCjeQOBDojIH6u1BVPtUExTh00cbA==
  dependencies:

This looks like an issue in JupyterLab instead of something which can be fixed in dask-labextension, am I right?

@fcollonval
Copy link
Member

Not really, it is a choice of the package manager (here yarn) to resolve the constraints:

  • @lumino/widgets@^1.17.0
  • @lumino/widgets@^1.37.2
  • @lumino/widgets@^1.37.2 || ^2.1.1

By installing the version 1.37.2 and 2.2.0 when actually 1.37.2 could resolve all of them (what would happen with pip or conda for example) - this is the pain of JavaScript packaging.

This is usually solved by working on reducing duplication with tool like yarn-deduplicate or by using package manager options; namely resolutions for yarn and overrides for npm.

@jhgoebbert
Copy link

Thank you, I think I understand now.

That makes things really difficult for everyone who provides extensions through PyPI as they do not know how the local package manager will handle this. 🤔
Could that be handled inside of jupyter_packaging->install_npm() as it is called from setup.py anyway:
( e.g. https://github.com/dask/dask-labextension/blob/main/setup.py#L65 )

@jtpio
Copy link
Member Author

jtpio commented Oct 9, 2023

There seems to be another issue with the @jupyterlab/rendermime-interfaces package.

The current main (targeting JupyterLab 4.1) defines the following version:

"version": "3.8.3-alpha.1",

While the 4.0.x defines this version:

So 4.0.x is "ahead" of main, which can be quite confusing and can also cause issues downstream when using the 4.1 packages, as noticed in jupyter/notebook#7096. Specifying ^3.8.3-alpha.1 or ~3.8.3-alpha.1 resolves to 3.8.6, but this creates incompatibility probably due to #15142 which updated some of the lumino dependencies.

Should the version of @jupyterlab/rendermime-interfaces on main be bumped to 3.9.0-alpha.1?

@jtpio
Copy link
Member Author

jtpio commented Oct 9, 2023

Also if we don't manually bump the version of the @jupyterlab/rendermime-interfaces now, it will likely create a collision when releasing JupyterLab 4.1.3 as it would bump to 3.8.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants