Migration to jupyterlab 4.0

[HaudinFlorence]

Hello,
@vidartf I am about to work on the migration of jupyterlab-git extension to jupyterlab 4.0 that depends on nbdime. Could you please give a hint about what will be the strategy concerning nbdime: is it planed to keep the compatibility with previous versions of jupyterlab or not?
Many thanks in advance.
cc @fcollonval

Tasks

Preview Give feedback

1. CM6: Fix border styles / line spacing #674
   +0
   
2. CM6: Fix background color #675
   +0
3. CM6: Fix missing mergeview pickers #676
   +0
   
4. CM6: Restore collapser #679
   +0
   
5. CM6: Several conflict gutter markers placed on the same line #700
   +0
6. CM6 tail: Merge view cell drag and drop #721
   +0
7. CM6 tail: Cell spacing #720
   +0
8. Add support for using cell ID in diffing and merging #639
   enhancement +1

[vidartf]

Hi,
I'm not sure yet how much work will be needed to add support for lab 4.0. I believe the main things of importance are:

• any changes for lumino 2.0. If there are any breaking changes that are not easy to support both at the same time, it can be hard to support both 4.0 and 3.0 with the same version. However, I think the actual change is for nbdime to support 3 + 4 instead of the current 2 + 3.
• any changes related to the codemirror version bump. I don' think it should be an issue, but maybe there will be some conflict if we try to put both on the page at the same time?
• others??

[fcollonval]

Hey @vidartf I'm supporting @HaudinFlorence in that migration effort. Could you elaborate the reasons for supporting 3 + 4? I don't see them as basically this project does not get much updates and it adds a huge amount of troubles to get the backward compatibility. I would rather have us spending time migrating nbdime to JupyterLab 4 / Lumino 2 / CodeMirror 6 rather than fighting with the backward compatibility that will likely be Lab 3 | 4 / Lumino 2 | 1 / CodeMirror 5.

[vidartf]

@fcollonval To try to rephrase myself:

I want to add support for JupyterLab 4. The amount of work needed to do that depends on how many things we use break with the lumino 2.0 upgrade. If there are no breakages, we might even be able to support both 3.0 and 4.0.

Separately there is the question of the Codemirror change in JupyterLab 4.0. As of yet, the CM "DiffView/MergeView" code that I used as a basis for https://github.com/jupyter/nbdime/blob/master/packages/nbdime/src/common/mergeview.ts has not been ported to CM6, so I do not think that we can quickly change to using CM6 for nbdime. Hopefully, it should not be a problem for us to continue using CM5 in nbdime with JupyterLab 4.0 though. I'd be interested to hear your thoughts on whether both of them can be on the page at the same time.

[vidartf]

Or maybe the mergeview code has been ported now? https://github.com/codemirror/merge not sure if this is it?

[fcollonval]

hear your thoughts on whether both of them can be on the page at the same time.

I think it should work as the API are totally unrelated (of course there is a performance cost but at least that would ease a first migration step). When trying to load nbdime without change in JupyterLab-git for JLab 4, the major issue seen is related to webpack configuration as for JLab 3, nbdime expect codemirror to be shared. Investigation is under way to see how to pass/fix that.

Or maybe the mergeview code has been ported now? https://github.com/codemirror/merge not sure if this is it?

We saw that repo too. But we have not checked it yet to see how it compares with the addon of CM5.

[JohanMabille]

It looks like the MergeView for CM6 supports the two-way view only, but it should be possible (and not too much complicated) to build a 3-way mergeview on top of it.

[CharlieJ15420]

Could you also add dependency support for jupyter_server 2.X.X please. Currently it only supports 1.X.X and lots of other extensions use 2.X.X. Thanks! :)

[vidartf]

Remaining tasks:
#674
#675
#676

[vidartf]

Note: An alpha version was released with #673

[fcollonval]

I started a task list in the first comment of this issue to track remaining issues to be addressed.

[fcollonval]

cc @krassowski - see tasks list; I proposed that contributor set them self as assignee when they start working on an issue to avoid conflict.

[fcollonval]

@vidartf @krassowski there are 4 nice to have PRs opened:

• Add translation for the frontend in Lab #709
• Fix editor background color #714
• Improve alignment #717
• Do not collapse editor lines in single editor #719

Mike also mentioned #639

Do we have other things mandatory for having a new final release of nbdime?

[vidartf]

Not mandatory, but it would be nice to have #636 as well, but that needs rebasing (pick up autoformat changes, cm6 changes) + needs some theming attention (new colors are not transparent, so struggle on themes, icons need to be reviewed if styleable by lab theme). Just mentioning for completeness.

[vidartf]

Also: #720

[vidartf]

#721

[krassowski]

Possibly #700 should not block the release, especially because after investigation it does not appear to be a regression due to CM6 migration?

[krassowski]

@vidartf @fcollonval It looks like we have everything that we wanted in for this release. Should we cut a beta or move straight to RC phase and announce intent to make a final release next week if nothing major comes up?

[fcollonval]

I'm 💯 on moving to rc and cut a final release as soon as possible.

[JohanMabille]

[krassowski]

I tried to publish an RC using the releaser but it failed (https://github.com/jupyter/nbdime/actions/runs/6770648492) because of insufficient rights.

Can someone else can pick it up or help with permissions?

[fcollonval]

Thanks Mike

I updated your rights. And I'm gonna give it a try. I'm not sure the version of the npm packages are gonna be set up properly with the releaser 🤞

[fcollonval]

... the JS packages are kept as alphas ... I'm gonna do a PR to migrate to rc.0. So they will be published as rc.1.

[fcollonval]

4.0.0rc0 has been released on PyPI
The NPM packages have version rc.1

The current limitations of the scripts/bump_version.py are:

• Version on the root package.json are not bumped because it is private and does not depend on the NPM packages
• NPM version does not switch between prerelease marker (alpha -> beta -> rc)

[vidartf]

Does the bump-version script ask for bumps independently for each target? Can we remove the private npm packages (webapp, root) as targets? It doesn't really do anything, and adds git noise. Or is that what you are saying is happening?

[vidartf]

FYI: I see the tag format changed from 3.2.1 --> v4.0.0rc1. Is that something we can normalize?

[fcollonval]

Does the bump-version script ask for bumps independently for each target? Can we remove the private npm packages (webapp, root) as targets? It doesn't really do anything, and adds git noise. Or is that what you are saying is happening?

The script does not ask anything as it is run within GitHub jobs. It tries to be smart. But we may have to do something like lumino; forcing us to create a PR to bump the NPM package versions before releasing.

FYI: I see the tag format changed from 3.2.1 --> v4.0.0rc1. Is that something we can normalize?

We can set RH_TAG_FORMAT in that environment, I think.

[vidartf]

Should we try to also get #718 in before release? The notebook metadata editors all collapsed bit.

[fcollonval]

Could we define an ETA for the final release?

[vidartf]

I think we can release today or tomorrow, and then do any of the remaining nice to haves in a quick minor release after?

[vidartf]

FYI: I see the tag format changed from 3.2.1 --> v4.0.0rc1. Is that something we can normalize?

We can set RH_TAG_FORMAT in that environment, I think.

Not sure if that is possible, since it seems to be hardcoded other places as well:
https://github.com/jupyter-server/jupyter_releaser/blob/811e16f4194b161331599582ecb30b3de659ac58/jupyter_releaser/lib.py#L39

[krassowski]

Do we want to wait for jupyter-server/jupyter_releaser#536?

[vidartf]

If it's a short wait that would be nice. Not sure how easy/hard it would be to clean up manually?

[fcollonval]

I'm doing a last rc right now to test the new tag format.

[fcollonval]

Here it goes: https://github.com/jupyter/nbdime/releases/tag/4.0.0rc1

The tag is correct - I needed to pin a custom fork of the releaser to use the bug fix. So I opened #738 as follow-up.

I'll do the final release this afternoon (around 4pm CET); let me know here if you want to postpone it.

[fcollonval]

🥁 i'm starting the final release

[fcollonval]

Ok final version has been released: https://github.com/jupyter/nbdime/releases/tag/4.0.0

[fcollonval]

But I think it is broken 💥 as CI is failing ---> investigating

[fcollonval]

Ok the error is due to the parsing of the version without release level.

I yanked 4.0.0 on PyPI.

[fcollonval]

4.0.1 is all green

[JohanMabille]

[vidartf]

Thanks @fcollonval and congrats on first release of nbdime! 🎉