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

[choldgraf]

(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.

[tonyfast]

thanks for pointing me to this issue @choldgraf

we're going to need help with the community and messaging since we know this effects so many folks. there is a proto jep in progress https://github.com/jupyter/notebook/issues/6220 that formally describes the goals. there is a community and messaging section where we could note any decisions y'all might make about UI.

i've added this to our project board as a reminder to touch base.

[betatim]

One thing we learnt from the switch to JupyterLab as the default UI for mybinder.org is that it was a much more disruptive change than we thought it would be.

This means that independent of what I think is the better choice to the default UI, I think we should think carefully about how much better it is and if it is enough of an improvement to justify the disruption it will cause (I'm resigned to the fact that no matter how hard we try it will be a disruptive change :-/)

Having said all that, I think changing the default UI that repo2docker (not BinderHub and not mybinder.org) offers can be done without as much disruption. Simply because repo2docker is used by a lot less people and those who do use it are more frequently interacting with it directly. It isn't a teacher who provides a link to students who are completely new to this whole thing (and therefore much less able to rescue themselves when confronted with an unexpected UI).

For a change on mybinder.org I think a good option would be to keep the current UI for all existing links, and for newly created links include something in the link that lets BinderHub recognise it as a "new" link that gets a new UI by default. For example bump the /v2/ to /v3/ in the links to signify "new UI please". Though that might cause confusion of a different kind, but at least all existing links would continue to behave as they currently do.

[choldgraf]

@betatim do you think we should open an issue specifically on mybinder-deploy to discuss the default binder behavior? Agree that this is a bigger decision and also separable from repo2docker behavior.

(And just to make clear I am not pre-supposing that we will make this change, I wanted to open this for discussion!)

[manics]

Is it worth having the discussion on the discourse forum instead of the mybinder.org-deploy GitHub? Especially since the choice of default behaviour isn't a technical discussion, it's much more about the user experience.

Regarding how we support different environments, I like the idea of specifying it in a file: https://github.com/jupyterhub/repo2docker/issues/868

If we're debating v2 vs v3 URLs that's probably worth a dedicated issue where we can consider other breaking changes. For instance the repo2docker base image Ubuntu 18.04 will go EOL in April 2023.

[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

[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.

[manics]

Notebook 7 is now the default version of notebook: https://github.com/jupyterhub/repo2docker/pull/1363

[minrk]

notebook 7 is the default implementation now, but the default UI is still JupyterLab. I think this Issue was about switching back to 'simpler' UI from full-blown Lab now that there's a modern version of the single-notebook UI built on the new stack.

[manics]

Reopened! I don't think we should switch though, JupyterLab has been the default for three years which is long enough that anyone relying on the old default UI will probably have updated any documentation or teaching materials to JupyterLab. If it had been a shorter time period the change back would be more justifiable, but I don't think we should force everyone to make another update now.