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

Jupyter Notebook version 7 #79

Merged
merged 30 commits into from
Dec 24, 2021
Merged
Changes from all commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
742681d
Add JEP for Notebook v7 early draft.
fperez Nov 13, 2021
1dfcb9c
Light editing
jasongrout Nov 13, 2021
684b57b
Merge pull request #2 from jasongrout/notebook-v7
jasongrout Nov 13, 2021
8d237f7
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 13, 2021
80f7924
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 13, 2021
90938bd
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 13, 2021
81d4dfa
Add Zach as an author
afshin Nov 18, 2021
cc7b5a7
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 18, 2021
4325335
Add a note about built-in features in JupyterLab
jtpio Nov 18, 2021
19da752
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 19, 2021
829efa9
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
5bdefe0
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
6bb9cc8
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 19, 2021
997c724
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
0fc957b
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
455b590
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
9f249f4
qUpdate NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
1a844d3
update to bullets, add experience gap to decision
fperez Nov 19, 2021
eff593b
Clarify language about transition
fperez Nov 19, 2021
7b558bd
Update NN-notebook-v7/notebook-v7.md
afshin Nov 19, 2021
d87a9b9
Alphabetize authors by last name.
fperez Nov 19, 2021
3e937a2
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 23, 2021
40d9179
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 23, 2021
9fd36b3
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 24, 2021
4e0512d
Update NN-notebook-v7/notebook-v7.md
afshin Nov 24, 2021
e69b16d
Update NN-notebook-v7/notebook-v7.md
afshin Nov 24, 2021
d6f487a
Remove empty bullet point.
SylvainCorlay Nov 27, 2021
3012995
Update NN-notebook-v7/notebook-v7.md
SylvainCorlay Nov 30, 2021
33ff157
Mark directory as 79 as per PR number, update authors list.
fperez Dec 2, 2021
b380c2e
Add note regarding extension authors user story.
fperez Dec 2, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
127 changes: 127 additions & 0 deletions 79-notebook-v7/notebook-v7.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
---
title: Build Jupyter Notebook v7 off of JupyterLab components
authors: (alphabetically) Sylvain Corlay (@SylvainCorlay), Afshin Darian (@afshin), Sharan Foga (@sharanf), Kevin Goldsmith (@KevinGoldsmith), Brian Granger (@ellisonbg) , Jason Grout (@jasongrout), Fernando Pérez (@fperez), Zach Sailer (@Zsailer), Jeremy Tuloup (@jtpio).
issue-number: 78
pr-number: 79
date-started: 2021-11-12
---

# Build Jupyter Notebook v7 off of JupyterLab components

This JEP presents a path forward for the evolution of the Jupyter Notebook application in a way that is technically consistent with the rest of our tools and thus more sustainable, while meeting the needs of our users.

This document proposes that the next major release of the [Jupyter Notebook](https://jupyter-notebook.readthedocs.io) application, version 7, will be based on the JupyterLab codebase, but will provide an equivalent user experience to the current (version 6) application. Jupyter Notebook version 7 ("Notebook v7" henceforth) will achieve this by using the current version of [RetroLab](https://github.com/jupyterlab/retrolab). The following three key ideas are central to this planned transition:

**The Notebook as a document-centric user experience:** The Jupyter Notebook application offers a _document-centric user experience_. That is, in the Notebook application, the landing page that contains a file manager, running tools tab, and a few optional extras, is a launching point into opening standalone, individual documents. This document-centric experience is important for many users, and that is the first key point this proposal aims to preserve. Notebook v7 will be based on a different JavaScript implementation than v6, but _it will preserve the document-centric experience, where each individual notebook opens in a separate browser tab and the visible tools and menus are focused on the open document_.

**Extensions critical to the Notebook user community:** Furthermore, for many users, certain widely used extensions are critical to their workflow. While we can not port every Notebook v6 extension ourselves (a list of widely-used community extensions is [here](https://github.com/ipython-contrib/jupyter_contrib_nbextensions)), we will identify some critical extensions (listed below) which, on day 1 of the Notebook v7 release, should work with similar functionality that users currently enjoy. We will engage with the developers of those extensions to identify a concrete technical plan and resources to implement this transition. We will also engage with the broader extension-authoring community to provide resources to ease the transition of other extensions.

**The body of existing content relying on the Notebook application experience:** Finally, the Notebook v6 community depends on widely-used educational content using the core Notebook application (such as tutorials, textbooks, videos), and these _will not be invalidated_ by the transition. Educators who have such materials online will not need to update their content. While we can not expect a pixel-perfect match between versions 6 and 7 of the Notebook, we will make every effort to ensure that the gap between the visual and operational experience (menu items, available tools and actions, etc.) is small enough that any user can reasonably bridge it without assistance.

These three concerns will drive our transition; their specific implications are detailed below in the form of concrete user stories.

## Extensions

The Notebook ecosystem for extensions is rich and varied, and some of those are critical to major deployments, especially in educational and institutional contexts. Since the internal APIs of JupyterLab are entirely different from those of Notebook v6, existing extensions written for v6 will not work on v7 out of the box. Here we detail the plan for how to minimize the disruption caused by this transition and how to support the community in the process.

There is a [community repository of unofficial Notebook extensions](https://jupyter-contrib-nbextensions.readthedocs.io), along with [corresponding documentation](https://jupyterlab-contrib.github.io/migrate_from_classical.html) indicating which of these extensions have analogs or ports in JupyterLab. Some of the functionalities provided by these unofficial Notebook extensions are now built-in features in JupyterLab: code folding, collapsible headings, the keyboard shortcuts editor, the table of contents, and many others.

### Critical extensions needed for Notebook v7

The following Notebook v6 extensions have been flagged by the community as critical to several major deployments and widely-used workflows. We will work with the extension developers to help port these (or help make new equivalent extensions) for Notebook v7:

- [nbgrader](https://github.com/jupyter/nbgrader)
- [RISE](https://github.com/damianavila/RISE)
- [Jupytext](https://github.com/mwouts/jupytext/issues/271)
- IPython Parallel (filebrowser tab)

### Extensions whose functionality will be built into Notebook v7

The following extensions will have largely equivalent experiences shipping in core Notebook v7 and JupyterLab. We will need to track whether there are any remaining differences in their functionality that are either regressions, or potentially disrupting or confusing to existing users.

- [Table of Contents](https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/toc2)
- [Collapsible headings](https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/collapsible_headings)

## Major new features in Notebook v7

In addition to having parity with the Notebook v6 user experience and widely-used extensions, Notebook v7 will inherit major new features that have been developed in the JupyterLab project, thus providing automatically a number of improvements to Notebook users as they transition to v7:

- Debugger
- Real-time collaboration
- Theming and dark mode
- Internationalization
- Improved Web Content Accessibility Guidelines (WCAG) compliance
- Support for many JupyterLab extensions, including Jupyter LSP (Language Server Protocol) for enhanced code completions

## Technical details

- [RetroLab](https://github.com/jupyterlab/retrolab) running on [Jupyter Server](https://github.com/jupyter-server/jupyter_server) will be the basis for Notebook v7.
- The current [RetroLab](https://github.com/jupyterlab/retrolab) commit history will be grafted into the [Jupyter Notebook repository](https://github.com/jupyter/notebook) in a pull request. When pre-releases of Notebook v7 are published, the `retrolab` package can be deprecated in preparation for archival after Notebook v7 final is released.
- Notebook v7 will continue to be released as the `notebook` Python package.
- Issues and PRs in the [Notebook repository](https://github.com/jupyter/notebook) will be triaged in this transition.

## Timeline

We anticipate that Notebook v7 will be released in 2022.

Jupyter Notebook v6 will be maintained with critical security fixes for two years following the release of Jupyter Notebook v7.

The [`nbclassic`](https://github.com/jupyterlab/nbclassic) Python package (which provides Jupyter Notebook version 6 on top of Jupyter Server) will also be maintained with critical security fixes for two years following the release of Notebook v7.


## User Stories
These user stories are guiding principles for the experience of using Notebook v7. They are not specific deliverables if the JEP is approved.

- As a user, when I install JupyterLab or Jupyter Notebook, I get both experiences, so I can choose between them as I work.
- As a user, when I start the application using `jupyter notebook` or `jupyter lab`, the default view that I see will correspond to notebook or lab respectively. The handler is also updated accordingly to point to that application.
- As a user, when I am using the lab or notebook interface, I can easily move back and forth within the UI using easily-discoverable menu items, context menus, buttons, etc.
- Open this document in the notebook interface
- Open this document in the lab interface
- Open this directory in the notebook file browser
- Etc.
- As a user, when I am using Notebook v7, the visual design strongly matches what I am used to in Notebook v6.
- As a user, I want the visual design of the notebook interface to get better over time, so my user experience improves over time.
- As a user, I want the visual design of Notebook and JupyterLab to be closely aligned, so I know that I am using a single, unified experience.
- As a user I want the UI to not change dramatically so that my tutorials and class materials do not get out of date.
- As a user, I want extensions for the file browser page of Notebook to be able to add new tabs that sit alongside the file browser (such as the Running Panel).
- As a user, I want extensions that need a left/right/bottom/status area to work in Notebook, but I want those areas to be entirely hidden by default, so I can have the document-oriented notebook experience that I am used to.
- As a user, I want to know all of the great new things I am getting with Notebook v7, so I can make an informed decision to upgrade.
- As a user, I want the most common notebook extensions to work in both the notebook and lab interfaces, so I can move back and forth without missing functionality (see below).
- As a user, I want this user experience to work seamlessly with the [Jupyter Desktop](https://blog.jupyter.org/jupyterlab-desktop-app-now-available-b8b661b17e9a)
- As a user, I can double-click on an `.ipynb` file on my local computer (Mac, Win, Linux) to open the notebook as a single document which I can edit, run, etc.
- As a user, I want to be able to go from the document-centric experience to the full JupyterLab Desktop application, so I can get a more IDE-centric experience, including file management, terminals, and more.
- As a user, I can open notebooks via the command-line or open JupyterLab in a particular directory.
- As a JupyterLab extension author, I want my extension to work with both Notebook 7 and JupyterLab 4, without maintaining two code bases or releasing two packages.
## Decision making principles

As we move forward with this plan and begin to make decisions about how to handle the visual design, functionality, and UX of Notebook V7 (how elements are styled, how do they behave, etc.) there will be tension between two paths:

* **Option A**: Making Notebook V7 work and look exactly like Notebook v6
* **Option B**: Making Notebook V7 work and look exactly like JupyterLab V4

There will always be tradeoffs between these two options. To help us make these tradeoffs, we propose to look at the following questions:

* Is Option A or Option B be more accessible?
* If we were to design this from scratch today, would our design work and look more like Option A or Option B?
* Is Option A or Option B more maintainable?
* Is Option A or Option B be more secure?
* Will Option A confuse or cause friction to Jupyter users who work in both Notebook V7 and JupyterLab v4?
* What is best for future Jupyter users who have never used either any version of Notebook or JupyterLab?
* Have we done everything possible to minimize the experience gap for users of Notebook v6 (while recognizing, given other constraints, that we can't always eliminate it completely)?
Comment on lines +95 to +110
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had an in person discussion recently that pushed me to comment on this section.

I'm in no way asking for a change, but I am going to write something I've said in the original governance call where this was started, and was unwilling to say/write again. Especially it was pointed out to me that others may feel similarly might not feel like expressing themselves.

I am aware that especially for this project it is better to all push in the same direction, and I hope that at least posting those thoughts here will at least reassure users that those concerns were expressed, heard, even if no change in current document are acted.


I am afraid this is the same framework that was used for JupyterLab, and for me this is not biased enough toward the "classic" notebook behavior. And I do believe this should be biased toward v6 users.
Our goal here is to provide a palatable transition to current classic notebook users. This framework and way of phrasing decisions targeted toward providing something "better" for end user (for whatever metric of better we choose), which tilts highly toward jupyterLab.

IMHO the framework would be better suited for a "version 7.5" than "version 7.0".
Especially since we don't have infinite manpower, and that we don't want to rehash all and every discussion I would have other concerns:

  • Is Option A or Option B be more accessible?
    • Is option A less accessible than current notebook classic v6 should be enough of a question.
  • If we were to design this from scratch today, would our design work and look more like Option A or Option B?
    • irrelevant, we know what the answer it's : the newer is jupyterlab so the response to this questions will always be B . The goal is to get users from classic to the new version.
  • Is Option A or Option B more maintainable?
    • This is also a non question, the answer will always be B: jupyterlab. The real question is always how much more maintenance burden we are willing to take to look more like classic.
  • Will Option A confuse or cause friction to Jupyter users who work in both Notebook V7 and JupyterLab v4?
    • Again wrong questions IMHO, and answer will always be B. We are not trying to cater to users using both. The question should be "is it worse than for users of v6 and Lab". Remember most users we are doing this for do do not use lab. It those users we are trying to please.
  • What is best for future Jupyter users who have never used either any version of Notebook or JupyterLab?
    • This is again broadening the scope and is the same questions that were asked and led to lab, and also not the users we should be catering to for 7.0

So while I as a person agree with the principle in the absolute and hope they will be reached in the future, I think in this context they are misguided, and would suggest caution of scope creep and repeating previous mistakes.

To TL:DR, we're not trying to write directly python 3.6 after 2.7, we are trying to write a 3.0 that sucks less for 2.7 users, like https://www.python.org/dev/peps/pep-0414/ (re-adding u-prefix to strings). Or for Physicist we are trying to have a quasi-static transformation, not a lower energy final state.

I will of course be a strong supporter of any decision that is taken, and trust the people more engaged in this than I. I also completely believe that even with the above framework the people involved will do the right decisions, but I'm concerned that it leaves the door open for interpretation and bikeshedding of every decision, and expands the scope of works far beyond what is necessary. I also believe the a clear, narrow and non-ambiguous scope of work make it much easier for drive-by and new contributors to participate as there is no frictions due to decision making.


So here is what I was refraining of posting, apologies as this is during the end of the comment period,I again do not ask for changes, and I am looking forward to notebook 7 !

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Carreau to make sure I understand, it sounds like you are suggesting that during the implementation of this JEP, a good rubric is:

  • For the purposes of Notebook V7, we should shoot for the minimal possible Notebook UI that builds on JupyterLab components, and that replicates Notebook V6 functionality. This is Notebook V7.0
  • Adding extra functionality beyond replicating Notebook V6 is a "nice to have", but should be secondary steps after we satisfy the step above. Better to do those iteratively, and imagine those as Notebook V7.1/2/3 etc.
  • Notebook V7.8 will redefine the .ipynb file format to be built entirely with walrus operators := (I kid 🙂)

Is that right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the questions in this section are less about what features/functionality Notebook V7 should have and more about how we should offer the features that are common between Notebook V7 and Lab 4 in terms of visual design, interaction design, behavior, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To Chris; Yes. Except I think the walrus operator should actually be a match statement.

To Brian, yes, and that is what I disagree with. The problem with framing that as "between V7 and JupyterLab" is that if frames V7 as a JupyterLab alternative, and that is not the reason we are doing this Jep:

This PR proposes a path forward for the user experience of the jupyter notebook application

The comparison should be V6, always. The fact that we are using JupyterLab components is an implementation detail – and important one for sure, but Lab behavior should not be the goal of the UI/UX. And I really really would like to avoid any mention that compare V7 to JupyterLab.

If I had to frame it in a different way, for me:

  • for v7.0: Any user facing difference in behavior from V6 is bug. The question is are we ok to live with it because the cost is too high.

There is nowhere in the above mention of Lab. Nor should there be.

Now if you want to tell me "for 7.3 we actually want to remove the "l" shortcut to toggle line number per cell as it's more consitent with Lab to always toggle all cells" i'm fine with that. But I don't think it is for 7.0.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I think about it is that when Notebook v7.0 is released, there are two voices that will be in a user's head:

  1. "I hope I can still do XXX - how do I do it?" (aka, we expect people want the same workflow in V7, and should minimize the disruption of the change)
  2. "I wonder what else I can do now that things are different!" (aka, people may want to extend their workflows into new directions with new functionality to explore what is possible)

I think @Carreau is suggesting (and I think I agree w/ this) that for an initial 7.0 release, it is more important to minimize #1 than it is to maximize #2. Finding new workflows will be useful for people, but it will happen more organically and over time. People are less likely to explore what the tools can do for them in the future if they immediately feel like their core workflow is disrupted. Moreover, people that strongly benefit from the workflows in JupyterLab are more likely to have already switched. For this reason, it's better to focus on "reduce the transition shock from V6 to V7" in this initial step.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now if you want to tell me "for 7.3 we actually want to remove the "l" shortcut to toggle line number per cell as it's more consitent with Lab to always toggle all cells" i'm fine with that. But I don't think it is for 7.0.

The effort that is currently ongoing in Retrolab is to get as close as possible to the notebook v6 user experience. Although there will definitely be some differences. The model that is proposed here is that any gap that remains between v6 and v7 should be small enough that users don't have a problem making the transition.


## Links and resources

- This JEP was originally posted by @fperez [as a comment in the original discussion opened by @zsailer](https://github.com/jupyter/notebook/issues/6210#issuecomment-957169113).
- The blockers for transitioning Berkeley's Data 8 course to RetroLab are tracked [here](https://github.com/berkeley-dsep-infra/datahub/issues/2422).
- The [community-contributed Notebook extensions have their own repository](https://github.com/ipython-contrib/jupyter_contrib_nbextensions).

## Questions

**Q:** What implications does this transition have for the notebook `.ipynb` format?
**A:** _None_. The file format remains unchanged. This JEP is about the Jupyter Notebook application, not the Jupyter notebook `.ipynb` file format.

**Q:** I wrote a Notebook extension that I'd like to update. Where can I find resources and/or support for that?
**A:** We will strive to assist the community throughout the transition to the new extension system. There will be a central location with information on how to port extensions for others to do so in the future. We will also host office hours to assist extension developers.

**Q:** What will I need to do to get my JupyterLab extension working with Notebook v7?
**A:** Both JupyterLab and Notebook v7 will use the same extension system and it is our intention to enable extension authors to create extensions that work in both JupyterLab and Notebook v7. We are still working out the technical details of that and will update our documentation with links as more information is available.