jupyter/docker-stacks

Jupyter Notebook deprecation

romainx opened this issue · 17 comments

romainx commented

Jupyter Notebook is deprecated and it is advised to transition to JupyterLab.

Please note that this repository is currently maintained by a skeleton crew of maintainers from the Jupyter community. We encourage users to transition to JupyterLab, where more immediate support can occur.

The recent issue #1205 has shown that keeping both may lead to issues.

The newly preferred backend for JupyterLab 3.0 is jupyter-server instead of notebook: https://jupyterlab.readthedocs.io/en/stable/getting_started/changelog.html#jupyter-server.

Roadmap

  1. Deprecation: Maintain compatibility with both backends and deprecate Jupyter Notebook. Jupyter Notebook remains the default but a message indicates that it is advised to transition to JupyterLab.
  2. Switch the default to JupyterLab: Switch to JupyterLab by default. It is still possible to start Jupyter Notebook by positioning a new JUPYTER_ENABLE_NB variable.
  3. Drop Jupyter Notebook: Move to jupyter_server alone and point people to nbclassic for a classic-like experience. It provides the Notebook UI as a new-server extension and also translates old-server extensions into new-server extensions. (To be clear, this isn't just something that looks like the Notebook UI, it is literally the same code, running through the compatibility layer.)

Note: Another option could be retrolab - the look and feel of the Notebook UI but built with Lab components.

Deprecation

Changes

  • With no option (no specific environment variable): Jupyter Notebook is launched (no change). However a warning / deprecation message is printed pointing to the dedicated section in the README.
  • With JUPYTER_ENABLE_LAB: Jupyter Lab is launched (no change).
  • Notice added in README

Switch the default to JupyterLab

Changes

  • With no option (no specific environment variable): JupyterLab is launched.
  • With JUPYTER_ENABLE_LAB: JupyterLab is launched. A warning message informs that this option is no more required.
  • With DOCKER_STACKS_JUPYTER_CMD=notebook: Jupyter Notebook is launched. This variable also allows to run other jupyter commands
  • Documentation is updated to document the new default and the new start option

Drop Jupyter Notebook support

  • Not planned

Changes

  • Jupyter Notebook support dropped (along with corresponding environment variables).
  • A solution providing a classic-like UI built atop of JupyterLab will be proposed. The solution is not chosen at this time.
parente commented

Noting that a convo opened in 2018 about making JLab the default in the Zero to JupyterHub tutorial has picked up steam again: jupyterhub/zero-to-jupyterhub-k8s#776 (comment) and includes a community poll.

  • 👀1
willingc commented

Let's look again at the date when these stacks will move to JupyterLab as the default front-end. April 2021 seems too aggressive a move and have the time to adequately inform those that expect classic.

romainx commented

Hello @willingc, thanks for the information. We can move the date, no rush on our side, it's just to reflect the message given by Jupyter Notebook maintainers. Could you please tell us what is the new target?

romainx commented

@parente & @willingc April is coming what is your advice? On my side, I have no strong opinion since I do not know the plans regarding Jupyter Notebook end of life. If we want to avoid unnecessary issues — like me — we could postpone the switch to a later date, for example June or October? Please tell me and I will take care of performing the change.

mathbunnyru commented

I would wait for Jupyter Notebook's decision regarding EOL.
I'm also not sure that all lab extensions are already updated to be compatible with jupyterlab 3.0.
And we have to give users more time to adjust their systems for jupyterlab.

parente commented

Since there's no votes here for switching in April and concern about it being too early, let's set the date further out. When Notebook no longer receives security fixes, when most other Jupyter projects make Lab the default (e.g., Binder, Z2JH), when there's a stable single-document interface for Lab akin to Classic, ... all seem like reasonable options to me.

romainx commented

@parente @mathbunnyru thank you for your very wise suggestions — one more time . I will take care to remove the date my saying something like "at some point", I think it's a better choice than setting a random date.

  • 👍1
krassowski commented

I wonder if https://github.com/jupyterlab/retrolab might ease the transition.

zeehio commented

Following this issue, I changed the default from the classic jupyter notebooks view to the jupyterlab and some users started complaining about notebook rendering performance, and browser hanging.

Apparently related to:

Just for you to consider that performance issue as a potential blocker for the jupyter notebook deprecation

krassowski commented

There was a lot of work on the performance, some released in 3.1 and 3.2, more coming to 4.0.

Which version of JupyterLab have you deployed? Was the slowdown specific to Firefox? Is it attributable to more notebooks opened, or is it also visible in RetroLab? We really need more real-world data to be able to address it.

zeehio commented

After looking at my colleague's notebook I was able to trim it down to a minimal example.

On Linux Mint 20.2 (based on Ubuntu 20.04), using Firefox 94 (latest as of today). I created a notebook on jupyterlab 3.2.1 with the following python code:

for i in range(10000):
    print("This is an example pointing to https://example.com and http://example.org")

Execute it to render the output, or run, save it and open it later. When the cell output is rendered things go wrong in Firefox:

Firefox RAM usage, as measured by the system monitor, with a just opened firefox with jupyterlab as the only opened tab and with only that notebook open, was going beyond 6GB and growing. I guess rendering all those links is very expensive.

Chromium 95 was much better: RAM usage was < 300MB, and the output rendered in ~10 seconds (may feel a bit slow opinion, but reasonable).

In case you wonder why such a long output with so many links, the real-world example that led to it in my colleague's notebook was a cell with !pip install <some-packages>. The pip output included >5k lines :

Skipping link: none of the wheel's tags (cp35-cp35m-win_amd64) are compatible (run pip debug --verbose to show compatible tags): https://files.pythonhosted.org/packages/d2/10/d20d757fbcbb49b3fdca2fd31c9236e233d72f1fcff5e2d0cd8993feb10b/Levenshtein-0.14.0-cp35-cp35m-win_amd64.whl#sha256=71562b3d288766e902c7ce5a8891d6cf7913031f00515b920f63d756cd4c3194 (from https://pypi.org/simple/levenshtein/) (requires-python:>=3.5)

So I'd say my minimal example is realistic.

Extra:

I tried it on a retrolab binder instance from https://gist.github.com/jtpio/77c82c512f6779a1a05ab59d915dfc36 and it was working fine.

I tried it on a jupyterlab binder instance from https://github.com/jupyterlab/jupyterlab and it worked fine (pip list --format=freeze reported a jupyterlab 3.2.0 there)

I tried it on my jupyterhub instance, with jupyter/minimal-notebook:lab-3.2.0, jupyter/minimal-notebook:lab-3.2.1 and jupyter/minimal-notebook:lab-3.2.2 and it is slow in all three cases.

mathbunnyru commented

@romainx I think we can and probably should proceed with this issue and change the default.

Rationale:

krassowski commented

I think that it is important to mention Notebook v7 JEP (discussion) in this conversation: Jupyter Notebook is here to stay, it is just getting a modernization/rewrite to use JupyterLab components and superpowers but it will retain its layout and features.

romainx commented

@mathbunnyru yes you're right I'm back 🤘
Thanks a lot for all of the valuable links. If you don't mind I will take some time to look at them 👀 in depth since the landscape is rich. I will comment back here.

  • 👍1
romainx commented

Hello,

Just a short update after reading most of the implementations. I'm wondering if the best solution to switch back to classic notebook is not to follow what has been done on binder: just indicate to use the URL http(s)://<server:port>/tree/. So there is no need to add a new variable as I proposed in the text of the issue (JUPYTER_ENABLE_NB). @mathbunnyru and @consideRatio if it's Ok for you I will update this issue and implement and document the change.

Best.

mathbunnyru commented

Sorry, @romainx I didn't understand how you want to proceed :(

romainx commented

@mathbunnyru you're right it was unclear. I mixed the two last steps of the plan. Forget that, it was not a good idea 😬. I will propose something in a PR.