-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Comments
Actually not sure if resetting the tag (for example manually) would help, or if JupyterLab will make it point to |
I fixed it manually - we should check at the next release if it is consistent or not. |
Thanks for checking out @jtpio |
Bumping to |
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.
The problem is that we updated the dependencies of We should bump the version of the packages to 4 or maybe allow both versions of Lumino. |
I opened #13647 some time ago for exactly this. |
Also |
Could switching to use the |
Yes, a new JupyerLab 3.6.4 which fixes its |
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. |
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? |
I tried to build the dask-labextension https://github.com/dask/dask-labextension for JupyterLab 3.6.4 but unfortunately it still fails with
I double checked if rendermime-interface 3.8.2 is really used and checked Two different versions of @lumino/widgets are the mismatch:
|
It works for me; the previously failing CI build of nbdime, is now passing smoothly. Locally a clean install after removing all |
I tried to build the dask-labextension https://github.com/dask/dask-labextension for JupyterLab 3.6.5 but unfortunately it still fails
|
@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 |
Thank you very much for the work-around!
This looks like an issue in JupyterLab instead of something which can be fixed in dask-labextension, am I right? |
Not really, it is a choice of the package manager (here yarn) to resolve the constraints:
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 |
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. 🤔 |
There seems to be another issue with the The current
While the
So Should the version of |
Also if we don't manually bump the version of the |
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 asnext
.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.Proposed Solution
We should reset the
next
tag to point to the3.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
The text was updated successfully, but these errors were encountered: