The future of nbclassic

[Zsailer]

This issue is in response to the Notebook v7 JEP.

Today, nbclassic depends on the notebook package (v6) for its HTML templates, static files, and javascript libraries. Upgrading to notebook v7 (i.e. retrolab) would break nbclassic.

The question remains, what should we do with nbclassic?

There are three directions we could go:

1. Keep NBClassic working as today—the classic Notebook UI with a Jupyter Server backend. We'd have to move the classic notebook templates, static files, and javascript to another package name; this is essentially forking the current notebook (v6) package and dropping it's Python tornado server in favor of Jupyter Server.
2. Shrink NBClassic's scope—make nbclassic become just a shim for server-side config/traits. Currently JupyterLab (any maybe other applications) use nbclassic to shim traits from NotebookApp to ServerApp.
3. NBClassic reaches end of life—we pin to notebook<7 and nbclassic cannot be installed next to notebook v7.

[Zsailer]

cc @tonyfast @jtpio @SylvainCorlay from our last notebook meeting.

also, cc @fperez @afshin, since we talked about this briefly when drafting the notebook JEP.

[jtpio]

Thanks @Zsailer for raising this.

Shrink NBClassic's scope—make nbclassic become just a shim for server-side config/traits. Currently JupyterLab (any maybe other applications) use nbclassic to shim traits from NotebookApp to ServerApp.

Maybe this would be the less disruptive approach, and would require minimal effort? And this could be extracted to its own nbclassic-shim package that would not depend on notebook. So jupyterlab can then depend on nbclassic-shim instead of depending on nbclassic.

Linking to jupyterlab/jupyterlab#11894 which drops nbclassic in JupyterLab to make JupyterLab 4.0 compatible with Notebook 7 (see original issue for more context: jupyterlab/jupyterlab#11612).

[jtpio]

Posting here more ideas that have been discussed at the Notebook Weekly calls: jupyter/notebook-team-compass#5

If we still want users to be able to use the classic notebook frontend after Notebook v7 final is released, one way could be to let nbclassic serve the classic notebook v6 frontend under different endpoints. In practice that means:

• retrolab is taking over the notebook name, endpoints (/tree, /notebooks...) and console script (jupyter notebook)
• nbclassic can still continue to live and:
  • add a dependency on notebook_shim
  • continue serving the classic notebook frontend (v6) under a different set of endpoints (/classic, /nbclassic or similar)
  • start with jupyter nbclassic

That way it might still be possible to allow installing JupyterLab 4, Notebook 7 and NBClassic alongside without conflicts.

[Zsailer]

nbclassic can still continue to live

This means we'd move the classic notebook Javascript into the nbclassic repo and allowing it to live on indefinitely.

A follow up question is, how do we handle the git history? I'm inclined to say we just move the code here in a PR and not worry about trying to disentangle the old commit history.

[echarles]

We have now a plan for the future as documented on jupyter/notebook-team-compass#5 (comment)

A follow up question is, how do we handle the git history? I'm inclined to say we just move the code here in a PR and not worry about trying to disentangle the old commit history.

I have opened a PR that takes over the git history for the static assets #93 Happy to get feedback on it. I am preparing other PRs (with git history) to add the docs, the tests...

[echarles]

The defined plan is now implemented. I will wait a few more days before closing this one.

[echarles]

Closing. Thx all.