Users item toolbar

[brichet]

Copy of #378, to try to fix the check_release workflow.

This PR provides a widget that can be used in a collaborative document to display current users.

This widget is a refactoring of a widget initially created in jupyterCAD.
Porting it to jupyter_collaboration has been initially discussed in jupytercad/JupyterCAD#496.

EDIT:

If the widget is integrated to a notebook for example, it looks like:

Code for the notebook widget (in Jupyterlab)

The Notebook is a special case because the document model can be null when first displayed. We need to handle the modelChange event.

• packages/notebook-extension/src/index.ts

    toolbarRegistry.addFactory<NotebookPanel>(FACTORY, 'usersItem', panel => {
      const container = new Panel();
      const onModelChanged = () => {
        container.widgets.forEach(w => container.layout?.removeWidget(w));
        container.addWidget(UsersItem.createWidget({ model: panel.model }));
      }
      onModelChanged();
      panel.content.modelChanged.connect(onModelChanged);
      return container;
    });

• packages/notebook-extension/schema/panel.json

   {
     "name": "usersItem",
     "rank": 1005
   }

[github-actions]

👈 Launch a Binder on branch brichet/jupyter_collaboration/users_item_toolbar

[martinRenou]

Is docprovider the right place for this, or should be in the collaboration package?

[brichet]

I asked myself the same question, and I put it here because it is really a document related widget, it supposed to handle the document current collaborators.
But I don't have a strong opinion on it, and can move it to collaboration.

[martinRenou]

Ok! I wouldn't know. Maybe @davidbrochart has an opinion on it.

[krassowski]

I would say that we should think about docprovider as enabling to use ydoc without collaboration, so anything which is collaboration-specific should go to collaboration unless it is impractical.

[jtpio]

Should this be merged now while jupyter-collaboration is currently in RC, with 3.0.0 final to be released in the coming days?

Or should this be part of a 3.1.0 release, since it's more of a new feature?

[brichet]

Should this be merged now while jupyter-collaboration is currently in RC, with 3.0.0 final to be released in the coming days?

Or should this be part of a 3.1.0 release, since it's more of a new feature?

Right, we should probably wait for the next release.

[jtpio]

Looks like this repo does not make active use of GitHub milestones, but it could be useful to start using them to track such issues and improvements.

I just created the following two milestones:

• 3.0.x: https://github.com/jupyterlab/jupyter-collaboration/milestone/4
• 3.1.0: https://github.com/jupyterlab/jupyter-collaboration/milestone/3

Feel free to move it back to the 3.0.x if you think this should be released sooner.

[jtpio]

btw @brichet if you have a screenshot / screencast around that could be posted in the description that would be really useful, thanks! (and we could also add it to the changelog when releasing this)

[brichet]

btw @brichet if you have a screenshot / screencast around that could be posted in the description that would be really useful, thanks! (and we could also add it to the changelog when releasing this)

Thanks, that helped me to finish this PR, I had only tested it with jupyter-collaboration v2 and forgot to copy the styles in there.

[martinRenou]

Thanks!

[brichet]

Should we merge this PR, since we are currently in a RC release ?
It was supposed to be in 3.1.0: https://github.com/jupyterlab/jupyter-collaboration/milestone/3

[davidbrochart]

We can release v3.1.0 and then merge this PR, what do you think?

[brichet]

We can release v3.1.0 and then merge this PR, what do you think?

Make sense, then we can probably release a 3.1.1, since this PR simply provide a new widget.

[martinRenou]

If we're strictly following semver, that should be a 3.2.0

[davidbrochart]

I don't mind having this PR in v3.2.0, but I think the release cycle is a bit overkill here (releasing alphas, betas, RCs...).
@krassowski what do you think about changing the releaser so that we can directly bump a minor version, without going through the full release cycle?

[martinRenou]

You should be able to run prep-release with 3.1.0 instead of next if you want to directly release 3.1.0?

[davidbrochart]

No, see the scheme to bump the version:

jupyter-collaboration/scripts/bump_version.py

Lines 15 to 52 in b3d8d29

	def increment_version(current, spec):
	curr = parse_version(current)
	if spec == "major":
	spec = f"{curr.major + 1}.0.0.a0"
	elif spec == "minor":
	spec = f"{curr.major}.{curr.minor + 1}.0.a0"
	elif spec == "release":
	p, x = curr.pre
	if p == "a":
	p = "b"
	elif p == "b":
	p = "rc"
	elif p == "rc":
	p = None
	suffix = f"{p}0" if p else ""
	spec = f"{curr.major}.{curr.minor}.{curr.micro}{suffix}"
	elif spec == "next":
	spec = f"{curr.major}.{curr.minor}."
	if curr.pre:
	p, x = curr.pre
	spec += f"{curr.micro}{p}{x + 1}"
	else:
	spec += f"{curr.micro + 1}"
	elif spec == "patch":
	spec = f"{curr.major}.{curr.minor}."
	if curr.pre:
	spec += f"{curr.micro}"
	else:
	spec += f"{curr.micro + 1}"
	else:
	raise ValueError("Unknown version spec")
	return spec

[martinRenou]

Ok, it seems I'm used to releasing jupytercad which does what I said: https://github.com/jupytercad/JupyterCAD/blob/main/python/jupytercad/scripts/bump-version.py#L49

[krassowski]

If there is a self-contained addition which warrants minor bump but not much else I am in favour of skipping some of the pre-release stages and e.g. going straight to RC (while bumping the minor) over just bumping the patch version.

[davidbrochart]

In the meantime, I think we can release v3.1.0, if everybody agrees.

[davidbrochart]

Sorry @brichet, but could you rebase one more time?

[davidbrochart]

Tests on Ubuntu all fail in main too 👀

[davidbrochart]

I cannot reproduce locally on my Debian.

[brichet]

Me neither on Ubuntu

[davidbrochart]

Let's merge and address the CI issue on Ubuntu separately.
Thanks @brichet.

[jtpio]

In the meantime, I think we can release v3.1.0, if everybody agrees.

FYI @davidbrochart next time when making a final release, you can check the following box when triggering the workflow

Otherwise the release does not show any merged PR, which is misleading: https://github.com/jupyterlab/jupyter-collaboration/releases/tag/v3.1.0

[davidbrochart]

Right, I forgot about that. I'm wondering if it should not be checked by default.