Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of nbclassic #81

Closed
Zsailer opened this issue Dec 3, 2021 · 7 comments
Closed

The future of nbclassic #81

Zsailer opened this issue Dec 3, 2021 · 7 comments
Labels
question Further information is requested

Comments

@Zsailer
Copy link
Member

Zsailer commented Dec 3, 2021

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 Zsailer added the question Further information is requested label Dec 3, 2021
@Zsailer
Copy link
Member Author

Zsailer commented Dec 3, 2021

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
Copy link
Member

jtpio commented Jan 19, 2022

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
Copy link
Member

jtpio commented Feb 11, 2022

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
Copy link
Member Author

Zsailer commented Feb 11, 2022

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
Copy link
Member

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
Copy link
Member

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

@echarles
Copy link
Member

Closing. Thx all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants