Critical extensions needed for Notebook v7 # 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. There is a community repository of unofficial Notebook extensions, along with corresponding documentation indicating which of these extensions have analogs or ports in JupyterLab. Here we detail the plan for how to minimize the disruption caused by this transition and how to support the community in the process. 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. The Notebook ecosystem for extensions is rich and varied, and some of those are critical to major deployments, especially in educational and institutional contexts. These three concerns will drive our transition their specific implications are detailed below in the form of concrete user stories. 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. Educators who have such materials online will not need to update their content. 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. We will also engage with the broader extension-authoring community to provide resources to ease the transition of other extensions. We will engage with the developers of those extensions to identify a concrete technical plan and resources to implement this transition. While we can not port every Notebook v6 extension ourselves (a list of widely-used community extensions is here), 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. 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.Įxtensions critical to the Notebook user community: Furthermore, for many users, certain widely used extensions are critical to their workflow. This document-centric experience is important for many users, and that is the first key point this proposal aims to preserve. 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. The Notebook as a document-centric user experience: The Jupyter Notebook application offers a document-centric user experience. The following three key ideas are central to this planned transition: Jupyter Notebook version 7 (“Notebook v7” henceforth) will achieve this by using the current version of RetroLab. This document proposes that the next major release of the Jupyter Notebook application, version 7, will be based on the JupyterLab codebase, but will provide an equivalent user experience to the current (version 6) application. 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. Build Jupyter Notebook v7 off of JupyterLab components #
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |