Default to RetroLab/Jupyter Notebook 7 if/when it is released

(note, I don’t know whether there is buy-in from people to do this, so don’t consider this a strong proposal but more like a continuation of the discussion in https://github.com/jupyter/notebook/issues/6210 without trying to disrupt the conversation that is here)

Proposed change

There’s a good discussion about the evolution of the Jupyter Notebook interface here, and one potential outcome (described in this comment) suggests that the Jupyter Notebook may morph into retrolab. AKA, in the next major release of the notebook (I believe v7), typing jupyter notebook will launch retrolab.

If and when that happens, I think that we should consider switching the default interface for repo2docker (and mybinder.org) back to use this single-document mode instead of the full-blown JupyterLab interface. This is for a few reasons:

• It more closely matches the primary UX that Binder users have had for the last few years
• It is a simpler interface that is more well-matched what I suspect many people want to do when “sharing a notebook on Binder”

Sort of a follow-up to https://github.com/jupyterhub/repo2docker/issues/1026

Alternative options

• We could keep using JupyterLab as the default interface.
• We could explore using a default interface depending on context - for example:
  • if somebody shares a Binder link that doesn’t point to a specific file, use JupyterLab as the interface
  • if it does point to a specific file, use the Jupyter Notebook interface.
• We could also explore making retrolab the default interface before the release of Notebook v7, if the switch will be inevitable

Who would use this feature?

A lot of people because this is suggesting that we change the default behavior of this tool, and thus mybinder.org - most people will just go with the default.

How much effort will adding it take?

I think there are three major areas of work for this, similar to what needed to happen for the JupyterLab UI change:

• Evaluating the state of “Jupyter Notebook 7.x” to make sure that there aren’t important regressions for our users (I suspect that the jupyter notebook team will make this evaluation themselves, so maybe this just means participating and watching discussions in that space)
• Signaling to our users somehow that this switch will be coming (maybe with a banner image on mybinder.org for a month or two) with documentation about how to get the behavior they’d want
• Making the switch itself (which I think means releasing in repo2docker, then deploying to mybinder.org). I would imagine this last bit is the least amount of work.

(and a final follow-up step, which is clearing up inevitable confusion that will happen when things change for our users in issues, discourse, etc)

Who can do this work?

I think the heavy lifting will be on the Notebook team to make the necessary upgrades. If that application looks to be in a good state for Binder use, then the biggest challenge will be:

• Deciding if we want to do this
• Coordinating amongst ourselves what kind of transition plan we want
• Messaging that to our users

The mybinder.org operators are needed for much of this, but I think it requires team conversation and a decision to happen.

[jtpio]

FYI the first Jupyter Notebook v7 pre-release is out: https://github.com/jupyter/notebook/releases/tag/v7.0.0a1

It works on Binder without changing the start script: https://mybinder.org/v2/gh/jupyter/notebook/main?urlpath=tree

The main difference is the jupyter notebook command now starting a Jupyter Server instead of a Classic Notebook Server.

[jtpio]

As an incremental step towards this, maybe there should first be a switch to Jupyter Server first?

It looks like the default command currently launches a classic notebook server:

https://github.com/jupyterhub/repo2docker/blob/00769c0fb2624558d600c6a24f14b4ba4154f4ce/repo2docker/buildpacks/base.py#L182