switch default server to jupyter-server-based jupyter-lab

[minrk]

This will launch jupyter-server, and be far more likely to be compatible with current repos than launching the old jupyter-notebook server.

It also makes the behavior of unauthenticated binderhub more similar to authenticated binderhub, which already does this same thing via jupyterhub-singleuser.

more detail in #1634

This is a breaking change, in that anything that relied on running the old server (mostly legacy extensions, which often, but do not always work) may break. But it's also a big fix, because now anything that relies on the current server is not broken (i.e. JupyterLab itself). I think this will result in a reduction of broken repos, but since it's a change, not a pure improvement, it's still a backward-incompatibility issue. It's also not great that repos cannot pick this, really, other than uninstalling jupyterlab, given how this works.

I can't seem to find it now, but I feel like we had a discussion and decided on switching the UI first (which we did a long time ago), and then switching the server at some later point, which is what's happening here. That was a long time ago, and I can't find it.

closes #1634

xref jupyter-server/jupyter_server#1038 - this should fix issues with jupyter-server 2.

[consideRatio]

Looks good to me, and makes sense to me

[minrk]

I think we should do this, and pretty soon. I think few users will be affected, but not none. I opened https://discourse.jupyter.org/t/binder-switching-to-jupyter-server-by-default/18011 to solicit feedback, since I want to do a better job communicating the change than we did with the UI switch.

[manics]

What are your thoughts on deploying this and other potentially breaking changes in repo2docker (e.g. default python 3.10) to mybinder.org- one change at a time, or combine them all into a single deployment and announcement?

[minrk]

How long do folks think is appropriate to wait for feedback on this one? The Python 3.10 switch has been announced for almost 6 weeks, with no objections, so I feel like that one's ready to deploy.

I'm not sure if it's better to deploy several breaking changes spread out over a week or two, or one big deploy that changes all 3.

[consideRatio]

I think one big. Less communication, and less states to consider if someone reports an issue - then one can know that either it was the big patch or not, as compared to before any patch, after patch 1, 2, or 3 etc.

[minrk]

Shall we do this update this week? We've received no feedback other than some hearts in 12 days so far.

[consideRatio]

@minrk I think that would be great! If I can help you with review or similar please do ping me and I'll try assist in such capacity

[manics]

Can we merge this now?

Then open a combined mybinder.org-deploy PR to bump both BinderHub and repo2docker, along with a prepared announcement to post to Discourse when the deployment PR is merged.

[consideRatio]

Merging to help offload with misc followups if issues surface in the CI system or similar!

[minrk]

I drafted a (probably far too wordy) description of the changes for the Jupyter blog: https://blog.jupyter.org/updating-defaults-on-mybinder-org-4df41d601955

[minrk]

jupyterhub/mybinder.org-deploy#2509 is the combined-update PR

[minrk]

@manics thanks for the review on the post! Going to publish and deploy.

[minrk]

Actually, I realized the blog post should have been an Issue on team-compass to make sure folks can review it. I'll do that and give it a bit more time.

[minrk]

This has been deployed.