Jupyter Blog - JupyterLab

JupyterLab 4.6 and Notebook 7.6 are out!

2026-07-02T16:13:00+00:00

JupyterLab 4.6 features new interface customization options, improved file browser and debugger, an easy way to jump between recently edited cells, and numerous other notebook experience improvements. Keyboard shortcuts, navigation and accessibility is another focus area in this release. Jupyter Notebook 7.6 has also been released, including the fixes and enhancements of JupyterLab along with a new Scratchpad console and other Notebook-specific improvements. This article highlights notable changes in both applications.

You can try out the changes in your browser: JupyterLab 4.6, Notebook 7.6
At the time of publication, the preview runs on JupyterLite 0.8.

Overview of some user interface enhancements visible in JupyterLab UI

Enhancements shared by JupyterLab and Notebook

Notebook improvements

Two new navigation commands, “Select previous last modified cell” and “Select next last modified cell”, allow jumping back and forward through recently edited cells. The commands are accessible from the Command Palette and as buttons in the Table Of Contents toolbar when a notebook is active.

Clicking the highlighted button will jump to a previously edited cell

Copy, cut, and paste text commands have been added to the notebook context menu. This feature requires permission to access clipboard to work reliably and may not work in Firefox depending on version and additional restrictions.

Copy/Cut/Paste Selected cells expose clipboard actions on cell source

The cell toolbar delete button now shows a confirmation dialog to prevent accidental deletion. The “Do not ask me again” checkbox is available and the preference is persisted in Cell Toolbar settings. The standard keyboard shortcut (D, D) is unaffected.

Dialog shown when deleting a cell from cell tollbar

Pressing Ctrl + B (Cmd + B on macOS) in a markdown cell wraps the selected text in bold formatting.

When exporting a notebook as HTML via File → Save and Export Notebook As → HTML, a dialog now asks whether to sanitize the HTML output before download.

File browser: new column, editable breadcrumbs, open in terminal

A new “Date Created” column has been added to the file browser, showing when files were created. The column can be toggled via Settings → File Browser → “Show date created column” or by right-clicking the column header. The latest jupyter-server (v2.18+) is required for accurate values across operating systems.

New date created column in file browser

The breadcrumb bar now supports direct path editing with tab-completion. Clicking the area behind breadcrumbs (highlighted on hover), or using the Command Palette, opens an editable text field where pressing Tab completes the longest common prefix of matching subdirectories.

Editable breadcrumbs

A new “Open in Terminal” option in the file browser context menu opens a terminal navigated to the selected directory. When multiple directories are selected, one terminal is opened per directory.

Opening terminal for a specific directory is now easier.

Additional file browser improvements include: a configurable file name sort order, persistence of the sort state across sessions, automatic clearing of the file filter when changing directories, and a loading animation during file browser refresh.

Debugger: kernel sources filter, floating overlay

The debugger Sources panel has been moved out of the debugger sidebar; the Sources now open as read-only editors in the main area, keeping the sidebar uncluttered while you explore the code state. The previous behavior can be restored by disabling the “Show Sources in Main Area” setting in the Debugger settings.

An overlay with continue/step in/stop buttons has been added easing the control of the debugger steps:

The Kernel Sources filter bar has been moved to the toolbar and now supports live filtering, making it easier to search through kernel source files while debugging.

The refresh button for sources list was removed — the sources will now update automatically after each code execution.

Keyboard navigation has been improved across several components:

The terminal no longer traps keyboard focus, allowing users to move focus away with the keyboard.
The console and file browser breadcrumbs both received keyboard navigation fixes.
Focus is now correctly restored after closing the command palette, and input elements in dialogs opened from the command palette receive focus immediately.
The find-and-replace button focus in the document search box has been corrected.

Screen reader behavior has been improved in the launcher and notebook. Toolbar buttons now correctly reflect their pressed state via the aria-pressed attribute.

The Keyboard Shortcuts settings panel has been updated to improve accessibility, including better keyboard interaction and screen reader announcements within the shortcuts editor dialog.

Focus indicators have been improved across the interface, including the status bar and other interactive components.

Keyboard shortcuts

Shortcuts can now be added from the UI shortcut editor for any command (previously this required writing JSON in Advanced Settings Editor).

“Find and Replace” has been added to the Edit menu with the keyboard shortcut Ctrl + H (Cmd + H on macOS).

Ctrl + Y has been added as a redo shortcut on Windows and Linux.

Pressing 1, 2, 3, 4, 5 and 6 will no longer convert a focused code or raw cell to Markdown to avoid accidental conversions. These shortcuts continue working on markdown cells, switching the heading level, as they did before.

Internationalization

Language packs can now be installed directly from within JupyterLab by selecting “Install more languages…” at the bottom of the Settings → Language menu. This opens the Extension Manager pre-filled with a search for available language pack extensions.

Terminal enhancements

Pressing Shift+Enter in the terminal now inserts a newline without executing the current line. This matches the behavior expected by certain terminal applications.

Inline completion enhancements

Inline completion suggestions can now be rendered with syntax highlighting that matches the active editor language. This can be enabled in Settings → Inline Completer → “Ghost text syntax highlighting”.

Ghost text is now also shown for all active cursors in a multi-cursor editing session.

JupyterLab-specific enhancements

Layout and interface customization

The activity bar can now be positioned at the top or bottom of the interface, in addition to the default left and right placement. The setting is available under Settings → Interface → Activity Bar Position.

Sections of accordion sidebars can now be moved between panels via a context menu. Right-clicking a section header shows a “Move To” menu. The placement and collapsed state of moved sections are persisted across sessions.

The sidebar panels themselves can be moved between areas. Right-clicking a sidebar shows submenu with options to move it to the main area, a different sidebar, or the down area.

Tabs can now be split in four directions using the “Split Tab” context menu item (or the command palette), which adds split left, right, up, and down options.

Individual panels can be zoomed in or out using Ctrl + mouse wheel (when “Enable Ctrl+ Scroll Zoom” is turned on in Settings → Interface) or via the command palette, without affecting other panels.

Performance

Panel resizing is now more responsive; the width of individual widgets inside resized panels is frozen during the drag. This behaviour can be disabled by toggling “Optimize panel resize” in Settings → Application Shell.

Notebook-specific enhancements

Scratchpad console

A scratchpad console can now be opened next to a notebook, sharing the same kernel. This makes it easy to run quick experiments or inspect variables without modifying the notebook itself.

The scratchpad console can be opened from the File -> New -> Scratchpad console menu, from the command palette, or with the Ctrl + B (or Cmd + B on macOS) keyboard shortcut, which toggles the console panel.

Confirmation dialog when closing and shutting down a notebook

The “Close and Shut Down Notebook” command now asks for confirmation before closing the browser tab and shutting down the kernel. The confirmation prompt can be disabled in the Settings Editor with the “Prompt for confirmation before closing and shutting down” setting.

Miscellaneous

Tab widths in JupyterLab are kept frozen while the mouse pointer hovers over them, making it easier to close multiple tabs with the mouse
Autocompletion heuristics were improved; the autocompletion (which remains opt-in) should no longer trigger in unexpected scenarios
The output scroll overlay collapse icon is now visible regardless of the output size and scroll state
The fonts used across components were standardized and fonts specified by themes or overrides are respected in every component of the application

For extension authors

Building extensions (and JupyterLab/Notebook themselves) is now ~5 times faster thanks to migration from webpack to Rspack. Building extensions no longer requires a full JupyterLab installation as the relevant machinery was extracted to jupyter-builder (see this blog post for more details). This (among others) enables faster build environment setup on CI. Future improvements to the build system can now be released independently of the JupyterLab release cadence.

Please refer to the Extension Migration Guide for more details on API changes and up-to-date advice.

As large as minor releases go

This JupyterLab release includes 68 new features and enhancements, 97 bug fixes, and 38 documentation improvements. 95 people contributed to this release. Across record-breaking 171 maintenance tasks we kept the dependencies up-to-date, improved quality of code and reduced the time to PRs getting merged by improving the CI performance and robustness. These efforts were in part funded by Jupyter Foundation Community Proposals.

While the size of minor releases fluctuated across years, this one is on the higher side, with only v3.1 featuring slightly more merged PRs. The reviewers worked hard to ensure no regressions are introduced, but if any slipped through, please open an issue in respective repository (JupyterLab or Notebook).

Acknowledgements

Thank you to all the new contributors, we hope to see you back!

JupyterLab (39): @aarondr77, @Akshitguptaa, @altis0725, @amanparganiha, @anafontan, @autodots-AHassan, @aviu16, @bittoby, @boskodev790, @chenjiahan, @cursoragent, @dhgoal, @DTiming24, @github29tani, @GlassOfWhiskey, @harshaagrawal20, @hroncok, @jayaprajapatii, @JaYRaNa213, @jianyexi, @ktaletsk, @lin9long, @mfisher87, @MMesch, @moktamd, @nightcityblade, @nthiery, @raffaelemancuso, @RamiNoodle733, @reteps, @rodrigosf672, @Siddhazntx, @statxc, @TheChyeahhh, @tsharma-dev, @tubaman, @u-wlkjyy, @Yahiewi, @ZhYGuoL
Notebook (9): @bodhisilberling, @Darshan808, @goelakash, @joaovml, @KH-Coder865, @Mirochill, @xlumzee, @yangsong97, @Yann-P

And thank you to returning contributors for their continued work!

JupyterLab (56): @aaron-seq, @afshin, @agriyakhetarpal, @AliMahmoudDev, @andrii-i, @apoorvdarshan, @arjxn-py, @arun-357, @bollwyvl, @brichet, @Carreau, @ceasermikes002, @cmarmo, @CrafterKolyan, @Darshan808, @davidbrochart, @DeborahOlaboye, @doshi-kevin, @erkin98, @fcollonval, @filipeoliveira05, @flaviomartins, @fleming79, @FoSuCloud, @frenzymadness, @HaudinFlorence, @i-aki-y, @ianhi, @ianthomas23, @IsabelParedes, @itsmejay80, @itsmevichu, @JamesWrigley, @jasongrout, @JasonWeill, @jimangel, @jtpio, @krassowski, @Krish-876, @linlol, @martinRenou, @Meriem-BenIsmail, @MUFFANUJ, @peytondmurray, @prajyot-porje, @pranshugupta01, @RRosio, @schmidi314, @soniya-malviy, @superlevure, @SylvainCorlay, @tmetzl, @utsav-develops, @xc2, @Yann-P, @Zsailer
Notebook (9): @andrii-i, @brichet, @Carreau, @jtpio, @krassowski, @martinRenou, @minrk, @RamiNoodle733, @takluyver

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab and Notebook issues: @RRosio, @krassowski, @andrii-i, @rodrigosf672, @ktaletsk among others who attend.

Announcing jupyter-builder: A Standalone Build System for JupyterLab Extensions

2026-06-19T13:11:00+00:00

We’re excited to announce the first stable release of jupyter-builder on PyPI and @jupyter/builder on npm. A standalone, configurable build system for JupyterLab and its extensions.

If you build or maintain a JupyterLab extension, this release is for you.

Motivation

For a long time, building a JupyterLab extension has meant installing all of JupyterLab. Take a look at any extension’s build dependencies and you’ll see jupyterlab listed there, not because the extension needs JupyterLab at runtime to be built, but because the build tooling lives inside the JupyterLab repository. The builder/ folder, the jlpm command, the helper scripts, they’re all coupled to the JupyterLab core.

This setup has caused real friction over the years:

Linux packagers have repeatedly raised concerns about the circular dependency where extensions like jupyterlab_pygments need jupyterlab to build, but jupyterlab ships with those extensions. It’s a chicken-and-egg problem that makes packaging painful.
Extension authors have to update their build system every time they update to a new JupyterLab version, which sometimes introduces breakages that have nothing to do with their extension’s actual code.
Users still occasionally run into installation issues that trace back to the incomplete migration from “source” extensions to prebuilt ones.

The need to separate the build system was identified back in jupyterlab#13456, and initial work began during GSoC 2024. With the support of the Jupyter Foundation’s first community-funded proposal, we’ve now brought that work to a stable release.

What `jupyter-builder` does

jupyter-builder extracts all the Node.js-based build tooling out of JupyterLab into a dedicated package. You install it on its own, and it builds your extension, no full JupyterLab installation required.

It ships in two parts:

jupyter-builder (PyPI) — the Python package that provides the jupyter-builder CLI.
@jupyter/builder (npm) — the underlying JavaScript package containing the build scripts. The Python CLI invokes build-labextension.js from this package, which then runs the rspack compiler with all the configuration needed to produce a JupyterLab extension.

Instead of jupyter labextension build ., you now run:

jupyter-builder build .

Build compatibility without JupyterLab installed

One interesting problem we had to solve: if JupyterLab isn’t installed, how does the builder verify that an extension is compatible with a given JupyterLab version?

The answer is @jupyterlab/core-meta, a small npm package that publishes JupyterLab’s core metadata on its own. @jupyter/builder declares a dependency on a specific @jupyterlab/core-meta version, so by default your extension is checked for compatibility against whatever JupyterLab version that pin corresponds to. In general, the latest @jupyter/builder will track the latest JupyterLab.

If you want to build against a different JupyterLab version, pass --core-version:

jupyter-builder build . --core-version 4.4.x

We’ll download that version’s metadata from @jupyterlab/core-meta on npm and check compatibility against it.

Migrating an existing extension

If you’re starting a new extension with the extension template, you’ll get all of this set up automatically. For existing extensions, there are two changes to make.

1. Update the Python build dependencies

In your pyproject.toml, swap jupyterlab for jupyter-builder:

# Before
requires = ["hatchling>=1.5.0", "jupyterlab>=4.0.0,<5", "hatch-nodejs-version>=0.3.2"]

# After
requires = ["hatchling>=1.5.0", "jupyter-builder>=1.0.0", "hatch-nodejs-version>=0.3.2"]

Then update the scripts section of your package.json to use the new CLI:

"build:labextension": "jupyter-builder build .",
"build:labextension:dev": "jupyter-builder build --development True .",
"watch:labextension": "jupyter-builder watch ."

Your build no longer pulls in all of JupyterLab.

2. Update the npm builder dependency

Replace @jupyterlab/builder with @jupyter/builder in your package.json:

"@jupyter/builder": "^1.0.0"

jupyter-builder is backwards-compatible with @jupyterlab/builder, so things will keep working if you don’t migrate immediately. That said, we strongly recommend switching: @jupyterlab/builder is no longer being actively developed, and all new work is happening in @jupyter/builder.

Note that as part of this transition JupyterLab has also moved from Webpack to Rspack. Most extensions won’t need any changes, but if yours uses a custom webpackConfig see the Rspack migration notes.

What’s next

This release is the first stable foundation. We’re continuing to:

Migrate more packages across the Jupyter organization to use jupyter-builder.
Make the builder more configurable, so it can eventually be used for projects beyond JupyterLab.

If you maintain an extension, please try the migration and let us know how it goes. Feedback from real extensions is the best way to make sure the migration path stays smooth.

Acknowledgements

This work was funded under the first round of Jupyter Community Funded Proposals. We want to thank the Jupyter Foundation and everyone involved in setting up this funding mechanism.

A huge thank you to Nicholas Bollweg for many thoughtful discussions on the design and packaging of jupyter-builder, and to Jeremy Tuloup for helping us resolve issues and for guiding the adoption of jupyter-builder in Jupyter Notebook.

This package was initially created during GSoC 2024 by Ronan Coutinho, mentored by Frédéric Collonval. Their work laid the foundation that made this release possible.

About the developers

Darshan Paudyal is an intern at OpenTeams and a member of the Jupyter Frontend Council. Darshan led the work to bring jupyter-builder to a stable release, completing the separation from JupyterLab core and shepherding the package through to its first published version.

Michał Krassowski is a Senior Software Engineer at OpenTeams. Mike provided guidance and technical direction throughout the development of jupyter-builder, helping shape its architecture and roadmap.

Useful links

📦 PyPI: jupyter-builder
📦 npm: @jupyter/builder
💻 Source: github.com/jupyterlab/jupyter-builder
📖 Migration guide: jupyter-builder migration section
💬 Issues & feedback: GitHub issues

A User’s Journey with Plugin Playground: From First Idea to Installable JupyterLab Extension.

2026-05-28T17:45:00+00:00

We are excited to announce the 1.0 release of JupyterLab Plugin Playground, allowing you to seamlessly experiment with the creation of Jupyter Notebook and JupyterLab plugins to add any functionality you may desire. To install:

pip install jupyterlab-plugin-playground

or use it from Binder or JupyterLite without installing anything by clicking one of these links: Binder (Lab), Binder (Notebook v7), JupyterLite (Lab), JupyterLite (Notebook v7).

Motivation

Building a JupyterLab extension has traditionally required setting up a complex local environment: installing dependencies from disjoint ecosystems (Node.js and Python), configuring tooling, and hunting down the right documentation. The goal of the Playground is to eliminate that setup overhead and streamline extension development. By bringing the runtime, documentation, and the context required for extension development into a single browser tab, you can go from idea to working extension without any local setup required.

Journey At a Glance

Start with a tiny extension idea that is easy to verify visually.
Choose a build path: Manual or AI-assisted.
Load and iterate inside JupyterLab until behavior is stable.
Build a second extension to prove the workflow is repeatable.
Share plugin files/packages for product and engineering review.
Export as a wheel(.whl) and validate installation in a clean Binder runtime.
Export as a zip and move the scaffold into a normal GitHub repository.

1.0: Pick Your Starting Path

At the beginning, choose the path that matches your confidence level and speed needs. If this is your first time with Plugin Playground, you can optionally run Take the Tour from the Launcher or Command Palette for quick orientation before starting.

Start from File If you already know the APIs you need and want direct control.
Build with AI If you know the intended behavior but want a first draft quickly.

Both paths converge to the same shipping workflow later.

2.0: Build Extension #1 Manually

For the first pass, we will create something small and observable.

Our Goal: add a command named Toggle Right Sidebar to the command palette.

2.1: Create the plugin file

Launch Start from File. This comes with a dummy template.

import {
  JupyterFrontEnd,
  JupyterFrontEndPlugin,
} from '@jupyterlab/application';

const plugin: JupyterFrontEndPlugin<void> = {
  id: 'hello-world:plugin',
  autoStart: true,
  activate: (app: JupyterFrontEnd) => {

  },
};

export default plugin;

Now build the plugin in order:

In Tokenssection in the right sidebar, search ICommandPalette and click insert ( + icon ), so Plugin Playground adds token import and dependency wiring.
Add a simple command skeleton inside the activate function:

const commandID = 'my-first-playground-plugin:toggle-sidebar'; 
app.commands.addCommand(commandID, { label: 'Toggle Right Sidebar', 
  execute: async () => {
      // place cursor here
  } 
});

In Commands, search application:toggle-right-area, place your cursor inside execute of the added command ( see above ) and use Insert in selection This adds at the cursor position:

app.commands.execute('application:toggle-right-area');

commandPalette.addItem({ command: commandID, category: 'AAA' });

After those edits, your file should look like:

import { ICommandPalette } from '@jupyterlab/apputils';
import {
  JupyterFrontEnd,
  JupyterFrontEndPlugin,
} from '@jupyterlab/application';

const plugin: JupyterFrontEndPlugin<void> = {
  id: 'hello-world:plugin',
  autoStart: true,
  requires: [ICommandPalette],
  activate: (app: JupyterFrontEnd, commandPalette: ICommandPalette) => {
    const commandID = 'my-first-playground-plugin:toggle-sidebar'; 
    app.commands.addCommand(commandID, { label: 'Toggle Right Sidebar', 
      execute: async () => {
          app.commands.execute('application:toggle-right-area');
      } 
    });
      commandPalette.addItem({ command: commandID, category: 'AAA' });
  },
};

export default plugin;

Uses the typed plugin template (JupyterFrontEndPlugin<void>) and typed activate parameters. Imports ICommandPalette so the plugin can add entries to the Command Palette.
Registers a new command (my-first-playground-plugin:toggle-sidebar) and executes application:toggle-right-area when your command runs.
Adds your command to the palette under the category AAA.

2.3: Load it and verify behavior

Click Load Current File As Extension or click the run button in the toolbar, and open Command Palette.

When you run Load Current File As Extension, Plugin Playground compiles the active file and registers the plugin object into the live JupyterLab session. During iteration, if a plugin with the same id already exists, Plugin Playground attempts to deactivate and replace it so reload loops stay fast.

Expected result:

Toggle Right Sidebar appears in the command palette ( open command palette by going through view -> Activate command palette or Press Accel + shift + C).

Running it hides/shows the JupyterLab right sidebar.

3.0: Build with AI

If you want a faster draft, use AI assistance for the same extension workflow.

Goal: add the Show Active Notebook Cell Count command with a friendly no-notebook fallback.

3.1: Give AI a precise request

Use Build with AI and give a prompt:

for example, something like:-

Create a JupyterLab plugin named "active-notebook-cell-counter".
Add a command "Show Active Notebook Cell Count".
If no notebook is active, show a friendly dialog message.
If a notebook is active, show the current cell count in a dialog.
Register the command in the command palette under category "Playground Demo".
Export default plugin object.

What this block does:

This gives AI a concrete plugin goal, command name, and fallback behavior requirements.

3.2: Use AI + deterministic inserts together

In the Commands tab:

Insert in selection for predictable boilerplate insertion.
Prompt AI to insert when placement context is tricky.
{n} when you need argument shape clarity ( Inspect the command signature before insertion: it shows expected argument names/types and return details).

Use Insert in selection for predictable snippets, and switch to AI when insertion location or code adaptation depends on the surrounding context.

4.0: Iterate Faster Before Handoff

Once the extensions run, enable Run on save(from the toolbar or from the settings) while polishing labels, command categories, and small behaviour details.

With Run on save, each file save triggers a reload loop for that plugin file, which makes label tweaks, command grouping changes, and message-copy iteration much faster than manual reload cycles. And with enabling the global setting (Load as extension on save), this behaviour is present for all files by default.

Before packaging, you can ask a teammate to review behaviour or just share links for the extension for a quick look using:

Share a single file when sharing is about one plugin file.
Share a package when your logic spans several files.

This keeps review lightweight: collaborators can inspect and discuss behaviour before you commit to repository structure, CI, and release wiring.

6.0: Export as Wheel and Validate in Binder

Now test as an installable artifact in a separate environment.

6.1: Export `.whl`

From the export dropdown ( in toolbar ), choose Export as Python package (.whl).

6.2: Install in Binder

Open JupyterLab on Binder.
Upload the downloaded wheel.
Open a terminal and run:

python -m pip install - force-reinstall ./your_exported_package.whl

What this block does:

Installs the wheel you just exported from Plugin Playground into Binder. (Uses — force-reinstall so Binder replaces any previously installed copy with your newest build). Then refresh JupyterLab and verify commands.

7.0: Export as Zip and Create a GitHub Repository

After runtime validation, move to normal engineering workflows.

7.1: Export `.zip`

Choose **Export as archive (.zip)** from the toolbar export dropdown.

7.2: Bootstrap repository

Unzip locally, create an empty GitHub repo, then run:

git init
git add .
git commit -m "Initial extension scaffold from Plugin Playground"
git branch -M main
git remote add origin https://github.com/<your-org-or-user>/my-jlab-extension.git
git push -u origin main

What this block does:

Initializes a new Git repository from the exported scaffold and creates an initial commit that captures the generated extension baseline.

Now your prototype is in a standard repo flow with PRs, CI, and release automation.

What’s Next

Plugin Playground is still evolving. We’re actively working on the LSP integration for JupyterLite to bring code intelligence autocomplete and diagnostics directly into the editor, an “Ask AI” button on log errors that lets you send error context directly into the AI chat for instant debugging help. In the future, we would like to explore git integration to snapshots every successful load, paired with a built-in diff viewer to compare any snapshot against your current file. If you have any suggestions or encounter any problems, please let us know by opening an issue on GitHub.

Acknowledgements

We are grateful to the Jupyter Foundation and its members for sponsoring the development of Plugin Playground as part of Community Funding Proposals 2025.

We thank Jeremy Tuloup, Nick Bollweg, and Nicolas Brichet for providing inspiration, review, and advice across our work on the plugin and its dependencies. Finally, this work would not be possible without the authors of earlier iterations of Plugin Playground.

About the Developers

Anuj Singh is an OSS intern at OpenTeams. Anuj implemented Plugin Playground v1.0.0 and contributed to its dependencies during his internship at OpenTeams.

Smera Goel is a UI/UX designer at Quansight. Smera contributed to the user experience and design direction of Plugin Playground.

Michał Krassowski is a Senior Software Engineer at OpenTeams. Mike provided guidance and direction for the development of the Plugin Playground.

700 JupyterLab 4 Extensions!

2026-03-13T17:18:00+00:00

700 extensions for JupyterLab 4, and counting!

The JupyterLab extension ecosystem just crossed 700 extensions compatible with JupyterLab 4!

That’s 700 community-built plugins — from astronomical data viewers to reactive notebooks, from genome browsers to workflow managers — created by hundreds of developers, research labs, and companies around the world.

What Are JupyterLab Extensions?

Extensions are how JupyterLab becomes a Git client, a dashboard builder, a genomics viewer, or an AI workspace — without changing the core application. Install one with pip install, and it activates automatically.

Popular JupyterLab extensions

This is by design: JupyterLab itself is built as a collection of extensions — the file browser, the notebook editor, the terminal are all plugins. The same architecture that powers the core lets the community build what they need. For background, see 99 ways to extend the Jupyter ecosystem.

The Ecosystem at 700

700+ extensions compatible with JupyterLab 4
~960 total extensions published on PyPI
~9.8 million downloads/month
100M+ total downloads in the past year

By any measure, a substantial software layer has grown around JupyterLab.

How We Got Here

The ecosystem crossed 600 JL4-compatible extensions in late October 2025, days before JupyterCon in San Diego. At the conference, we ran a full-day Extension Development for Everyone tutorial with hands-on rapid prototyping. By early March 2026, we hit 700.

The ecosystem has been growing at a steady pace, averaging about 18 new extensions per month, with November 2025 setting an all-time monthly record of 33. Modern tooling is helping: better templates, documentation, and code generation tools have lowered the bar for what once required deep familiarity with TypeScript, Lumino, and JupyterLab internals.

Where the Extensions Are

Number of JupyterLab extensions by category

Monthly PyPI downloads by category

Development & Version Control dominates both in count (267) and downloads (5.4M/month). Visualization & Dashboards (2.7M/month) and System & Resource Management (602K/month) round out the top three most downloaded categories. But the fastest-growing categories point to where things are heading. Here’s what’s new in 2026:

JupyterLab’s AI Layer Starts Taking Shape

AI isn’t yet the biggest category in JupyterLab, but it may be the clearest signal of where new interaction patterns are emerging:

jupyter-ai-acp-client — Brings external AI agents into JupyterLab’s chat via the Agent Communication Protocol. Ships with Claude Code and Kiro personas.
nb-margin — Annotate cells with margin comments, and Claude Code edits them. A different paradigm from chat-based AI.
jupyterlite-ai-kernels — AI-powered kernels for JupyterLite, from Jeremy Tuloup. AI-assisted computation entirely in the browser.
jupyter-chat-components — Reusable chat UI components from Project Jupyter — building blocks for the next generation of AI tools.

These extensions reflect what the JupyterLab team identified as a 2026 priority: first-class integration with AI tooling.

Reproducibility Gets a Toolchain

calkit-python is the most downloaded new extension of 2026 (11,000+ monthly downloads). It gives notebooks project-scoped environments, graphical package management via Astral’s uv, and one-click notebook pipelines with freshness tracking. Think “Makefiles for notebooks” meets “Poetry for Jupyter.”

Calkit manages notebook pipelines with environment tracking and one-click reruns. The orange ‘run’ button signals stale outputs that need to be regenerated.

jupyter-projspec (from the fsspec contributors) takes a complementary approach — it brings projspec into JupyterLab, letting you scan and analyze project structures directly from the notebook environment.

jupyter-projspec integrates to system filebrowser to show the project metadata

Science

fitsview — Stream FITS astronomical data slices directly in JupyterLab without downloading full files.
jupyterlab-urdf-test — 3D robot model viewer/editor (URDF + Three.js), from jupyter-robotics.
climb-jupyter-igv— Integrative Genomics Viewer with S3 access for bioinformatics.
ggblab— GeoGebra interactive geometry with bidirectional Python communication. Second most downloaded new extension of 2026.

Accessibility

Accessibility has been a growing focus for JupyterLab core and extensions are starting to address it too:

jupyterlab-a11y-checker— From UC Berkeley’s DSEP infrastructure team, this extension scans notebooks for WCAG 2.1 AA issues: missing alt text, heading structure, table headers, color contrast, and link text. Guided fix interfaces, optional AI suggestions, and a CLI for CI pipelines. Over 11,000 total downloads and a documentation site.
jupyterlab-change-ui-font-size-fix — Fixes file browser icon misalignment when users change the UI font size — a small but real pain point for anyone who needs larger text.

27 Extensions, One Platform

Stellars is a JupyterLab-based data science platform — GPU support, MLflow, TensorBoard, Optuna — assembled from 27 custom extensions covering everything from branding and file icons to kernel management and diagram rendering, VS Code file icons, trash management, Mermaid-to-PNG conversion, and more.

JupyterLab is now flexible enough that one developer can assemble a domain-specific product entirely from extension building blocks.

Want to Build Your Own?

The JupyterCon tutorial is fully available: step-by-step materials and the complete YouTube recording. It covers scaffolding, plugin architecture, publishing to PyPI, and rapid prototyping techniques. The tools have never been more accessible.

How We Track This

The data behind this post comes from the JupyterLab Marketplace, a community project that tracks all published JupyterLab extensions using PyPI data. The marketplace refreshes automatically and provides download trends, category breakdowns, and discovery tools.

JupyterLab Marketplace

For more on the data and methodology, see our PyData Boston 2025 talk.

What’s Next

New interaction patterns are still being figured out — chat-based assistance, cell annotations, agent protocols. Probably all of them for different use cases.
Reproducibility tooling suggests the community is ready for opinionated workflow management built into the notebook experience.

Ensuring extensions keep working as JupyterLab evolves is critical — the team has been discussing extension compatibility testing at recent contributors calls.

For the Marketplace itself, we’re working on:

Deeper integration with JupyterLab Extension Manager — deep links and “Install in JupyterLab” buttons to go from discovery to installation in one click.
Expanding Trove classifiers to indicate Jupyter Notebook and JupyterLite support. All three use the same extension system, with important caveats: Notebook extensions need to target different UI elements, and JupyterLite extensions cannot have a server component.
Better contribution signals — surfacing commits, PRs, and issues to help users gauge how actively maintained an extension is.

At 700 extensions, the community now shapes JupyterLab as much as the core team does. If you’re building extensions, thank you! Every one of them makes Jupyter better for someone.

About the author

Konstantin Taletskiy is a Senior Software Engineer at Anaconda working on open-source Jupyter. He is a contributor to JupyterLab, maintainer of mamba-gator and jupyterlab-latex, and the creator of the JupyterLab Marketplace.

Instantly view Parquet files in JupyterLab with Arbalister

2026-01-29T16:18:00+00:00

A colleague sends you a SQLite file, a Parquet dataset, or an Avro snapshot.
You need to explore the content, but you’re not sure what’s inside or even how to open it. You shouldn’t have to write code, craft SQL queries, or recall the syntax for read_parquetin a Python library. Instead, you should be able to click the file once and instantly see the tables and metadata.

Despite being the de-facto standard for data science and exploration, JupyterLab lacks this basic capability out of the box. Of course, there are extremely well designed libraries to read, process, and transform tabular data — but opening and viewing a file with a table should be simpler. A workflow with libraries like Pandas or Polars require you to install relevant packages, create a notebook, and iterate on queries to get a full picture of the data.

import pandas as pd

pd.set_option("display.max_rows", 50)
pd.set_option("display.max_columns", 20)
pd.set_option("display.width", None)

df = pd.read_parquet("data/2025/PERFORMANCE_SNAPSHOT_2025_01_05.parquet")
df

Whether for a newcomer to data science, or someone that needs to investigate many different files with hard to remember schemas, this is a bit cumbersome. Comma separated value files (CSV) have better support: double click on the file to see it open (see figure below). That is a great way to understand the business logic and answer questions such as What type of information is in this file? What do values typically look like? Does it seem to contain all the data I need? What is the difference between customer_id and user_id?

The JupyterLab CSV viewer

Arbalister, our new JupyterLab extension, changes this. With Arbalister, you can double-click to instantly view a wide range of tabular data files: Parquet, CSV, Avro, ORC, SQLite, and more…

Arbalister viewer can open Parquet files and more

The extension will load data as it is displayed, making it possible to view it almost instantaneously even if the file does not fit in memory. A toolbar lets the user select some reading options, such as the delimiter for a CSV file, or selecting the table to display in the SQLite file!

Arrow over the wire

Fueling it all is the Apache Arrow ecosystem, an in-memory format for tabular data used in most data science libraries. Plenty of files types can already be read into an Arrow data structure so we exploit it heavily in Arbalister (with Apache Datafusion in our case).

The table displayed in the user’s browser reuses JupyterLab Lumino DataGrid with a custom data model. In the latter, we divide the whole table in chunks across both the rows and columns axes (e.g. 512 rows and 24 columns). When we need to display data from a chunk that is not already available, we make an HTTP request to a server-side extension that open the file, read the relevant portion into an Arrow table and return it to the client. The table is returned as Arrow IPC (Inter Process Communication, a binary format close to the original Arrow memory) in the response body. In the client, a lightweight Arrow implementation can read it back efficiently.

Arbalister client-server architecture

When nothing else is happening, the implementation will also pre-fetch some of the next chunks in the background so that scrolling past a chunk boundary is imperceptible.

Because it all works in Arrow, which is standard for tabular data, adding support for new types of files that can be read into the Arrow format is extremely easy. Vortex, Lance, or whichever other format becomes relevant. But that is not all…

The existing SQLite support is made possible through ADBC, an SQL connector that reads databases into Arrow format. SQLite databases fit into single files, which fit the abstraction used in Arbalister, but ADBC could also be used to add general database exploration (Postgres etc.) into Arbalister. With Datafusion, we could also add visualization for data lakehouses: partitioned datasets (e.g. DeltaLake or Apache Iceberg) over remote object storage (S3). With Intelligent predicate and projections pushdowns, we could visualize remote tera-byte table instantly by only downloading the relevant parts.

Looking further

There are multiple things that would make great improvements to Arbalister. We have already mentioned:

Optional support for newer file types: Vortex, Lance;
Object storage and data lakehouses support;
SQL databases support.

Another direction is support for JupyterLite, a WebAssembly distribution of JupyterLab running entirely in the browser. This setting is great for education because it does not require more than a static file server to host.
Being able to work directly with Parquet files in the browser is great for making dashboard and interactive demonstrations. Arrow and Datafusion already have some experimental support for WebAssembly so this is not so far-fetched.

Finally Arbalister could use a few features to investigate deeper questions about the data. For instance, beyond the What does the data look like? question, some column filters could help answer questions such as What does the data look like in November 2024 for John Doe? Perhaps even an SQL console for more advanced queries.

An extension point

The server extension being only a way to serve Arrow data, it can be reused by other libraries to use it in other ways. For instance, if we knew that our table contains time-series data, a second viewer could display it as a graph.
Similarly for geospatial data.

If you are interested to use or contribute to Arbalister, head to our GitHub!

About the Author

Antoine Prouvost is a senior scientific software engineer at QuantStack. His work on Arbalister was funded by Bloomberg.

JupyterLab 4.5 and Notebook 7.5 are available!

2025-11-24T09:32:00+00:00

JupyterLab 4.5 has been released! This new minor release of JupyterLab includes 51 new features and enhancements, 81 bug fixes, 44 maintenance tasks and 38 documentation improvements. There were 51 contributors to this release.

Jupyter Notebook 7.5 has also been released, including many of the fixes and enhancements in this JupyterLab 4.5 release. While the releases on GitHub provide additional detail on the updates made to both JupyterLab 4.5 and Notebook 7.5, this article highlights some particularly notable changes.

Extension authors can refer to the Extension Migration Guide for information on API updates and details regarding changes to core packages.

Performance and windowing

The default windowing mode is now contentVisibility which improves cell rendering and alleviates previously reported issues. The minimap can be enabled for all windowing modes and all notebooks via the Settings menu, or by toggling the minimap per notebook with the View -> Show Minimap option. Additional fixes improve layout containment and scrollbar behavior when working with long cells.

Notebook improvements

Saving large notebooks is now faster and more responsive thanks to streamed uploads and users can now open notebooks without starting a kernel, via the Open With context menu option.

Open a notebook without a kernel

Markdown support has been expanded for using grid and flex based layouts and the Table of Contents has been significantly improved to better handle markdown headings, fixing issues with HTML tags, comments, and horizontal lines.

Copying and pasting cells across browser tabs is now supported and the “Line Wrap” toggle in settings now correctly applies line wrapping to cells.

Other improvements include: restored scrolling to in-notebook links, manual saving support in collaborative mode, and improved performance and memory usage when streaming text outputs.

Debugger and Console improvements

The debugger’s evaluate dialog has been replaced with an interactive console with syntax highlighting and code completion, and the variables panel now preserves its contents when switching editors. Selected breakpoints are now visually highlighted and breakpoints correctly handle empty lines and duplicate clicks. A visual indicator is displayed when the debugger is paused.

Debugger panels as well as console debugging panels now reference the cell execution count helping users relate breakpoints, call stacks and source code to the cells they originate from.

JupyterLab 4.5 includes many improvements to the debugger

For the Log Console, users can now configure the default log level via settings, as well as customise the toolbar.

New search functionality inside terminals

The terminal now includes search functionality, with search highlights that adapt to theme changes.

Search is now compatible with terminals

Media and content support

JupyterLab now includes built-in audio and video viewers, allowing users to open audio and video files directly from within JupyterLab.

Open audio and video files in JupyterLab

File browser enhancements

Uploaded files can auto-open, with controls for size limits and behavior, and a new allowFileUploads setting provides control over upload permissions.

There is now a menu option for creating new Python, R, or Julia files, and a “Select All” command has also been added, also accessible via the Ctrl + A keyboard shortcut.

Users can now configure file browser breadcrumbs through the settings editor options breadcrumbsLeftItems and breadcrumbsRightItems.

JupyterLab 4.5 includes many improvements to the file browser

Updates to file dialogs and navigation have addressed column spacing, preferred-directory handling and double-click behavior.

Keyboard shortcuts and commands

Code fold and unfold commands have been added and shortcuts for these can be set in the settings editor.

The “Show Workspace Indicator” command has been added to the command palette and the “Send Code to Console” shortcut has been restored. The previous issue involving editing shortcuts on Safari loosing focus, has been resolved.

With Jupyter Notebook 7.5.0, the O key has been defined as the keyboard shortcut to toggle cell outputs, restoring this familiar functionality from the classic notebook.

Settings

The settings editor now supports a toSkip configuration to hide specific plugins from view.

A new setting, addExtraLineOnCellMerge, allows to remove the extra line added when merging cells, which is expected behavior based on the classic notebook.

User interface and accessibility

JupyterLab can now automatically switch between light and dark themes when “Synchronize with System Settings” is enabled.

Dialog components display buttons and checkboxes on separate lines for better readability, and selections in the terminal under high-contrast themes have better visibility.

Keyboard navigation and tab order in the status bar has also been improved.

Update from JupyterCon

At JupyterCon 2025 in San Diego, the Jupyter Frontends team presented an update on features released since JupyterLab 4.0. This session covers the progress made since the previous conference in 2023. You can watch the full recording below.

Acknowledgements

Thank you to all the new contributors, the Jupyter Frontends team hopes to see you back!

JupyterLab: @Ankitaupadhaya, @CrafterKolyan, @EtiennePelletier, @Frank-Steiner, @Meriem-BenIsmail, @arjxn-py, @bnavigator, @bsundaram1, @dnlzrgz, @dotnetautor, @gjmooney
Notebook: @honnix, @jchen1223, @sangampaudel530

And thank you to returning contributors for their continued work!

JupyterLab: @Darshan808, @DenisaCG, @HaudinFlorence, @MUFFANUJ, @RRosio, @SylvainCorlay, @achhina, @afshin, @andrii-i, @bollwyvl, @brichet, @choldgraf, @cmarmo, @davidbrochart, @ianthomas23, @isabela-pf, @itsmevichu, @jasongrout, @jrdnbradford, @jtpio, @kathatherine, @kr-2003, @krassowski, @mahendrapaipuri, @martinRenou, @minrk, @nkn2022, @peytondmurray, @ritzdevp, @robertstrauss, @rschroll, @shreve, @skapin, @trungleduc, @yacchin1205, @yukiiii04, @zanieb
Notebook: @choldgraf, @itsmevichu, @jasongrout, @jtpio, @krassowski, @minrk

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab, Notebook and JupyterLab Desktop issues: @RRosio, @krassowski, @andrii-i, @danyeaw among others who attend.

JupyterLab 4.4 and Notebook 7.4 are available!

2025-05-21T09:54:00+00:00

JupyterLab 4.4 has been released! This new minor release of JupyterLab includes 28 new features and enhancements, 76 bug fixes, 63 maintenance tasks and 34 documentation improvements. There were 56 contributors to this release.

Jupyter Notebook 7.4 has also been released, including many of the fixes and enhancements in this JupyterLab 4.4 release. While the releases on GitHub provide additional detail on the updates made to both JupyterLab 4.4 and Notebook 7.4, this article highlights some particularly notable changes.

Extension authors can refer to the Extension Migration Guide for information on API updates and details regarding changes to core packages.

Code console improvements

The code console prompt can now be positioned on the top, left, or right side of the console, in addition to the default bottom placement. The placement is persisted in the Prompt Cell Position setting. The console toolbar now includes buttons to:

Execute code
Restart the kernel
Clear the cells
Switch the kernel

Changing the position of the prompt cell in JupyterLab code consoles

Additional settings for console behavior have been added:

Clear Code Content on Execute (enabled by default) — When disabled, the code submitted for execution remains in the code editor, allowing for further edits.
Hide Code Input — When enabled, only the execution output is shown in the console.
Clear Cells on Execute — When enabled, only the last cell is displayed.

Toggling all the three new settings transforms the console into an interactive editor resembling an ephemeral notebook with a single cell.

The code console configured as a single executable cell

Settings import and export

Settings can now be exported to overrides.json from the Settings Editor, which can be used to pre-configure defaults in deployments or to restore settings.

Import and export settings from the Settings Editor

Workspace indicator

An opt-in workspace indicator is displayed on the top bar (next to the menu bar). It can be enabled in the Settings → View → Appearance → Show Workspace Indicator:

The workspace indicator

Support for collaboration without `RTC:` drive

Real time collaboration in previous versions of JupyterLab (which can be enabled by installing jupyter-collaboration package) was implemented by swapping the default JupyterLab file system drive to a collaborative drive with the RTC: prefix. This approach was incompatible with multiple extensions. JupyterLab 4.4 introduces the Content Providers API, which allows the next version of jupyter-collaboration to work without changing the drive prefix. This improves compatibility with extensions that do not support arbitrary drives.

Kernel subshells support

Kernel subshells, introduced in JEP 91, enable concurrent code execution in kernels that support them. When performing long-running computations (such as training a model), subshells enable users to:

Use ipywidgets with updates displayed immediately
Monitor kernel resource usage (e.g. memory usage)
Invoke arbitrary commands (e.g., refine code for a subsequent cell) while maintaining live access to previously defined variables

Subshells are supported by ipykernel 7 (currently in alpha).

To create a subshell, open context menu (right-click) over a notebook using a kernel supporting subshells and select “New Subshell Console for Notebook”. A new console panel will open allowing access to variables from the main session.

Creating a new subshell console for a notebook in JupyterLab 4.4

JupyterLab can automatically create subshells for comm messages if kernels support this feature. This enables concurrent execution of ipywidgets callbacks without requiring a user action. This behavior can be changed from the settings, with options to:

disable that feature to not use subshells for comms
(default) automatically create one subshell per comm-target (e.g. one subshell for all ipywidgets)
automatically create one subshell per comm (this can lead to issues if creating many comms)

The context menu, available under right mouse click in browsers, can now be disabled globally by toggling the Enable Context Menu option available in the Command Palette, or via the JSON Settings Editor in the Application Context Menu.

Slimmer status bar

The terminals counter no longer appears in the status bar if no terminals are open. The kernels counter can be disabled by toggling the Show the status bar item setting in Running Terminals and Kernels (code name showStatusBarItem).

Walkthrough video

If you prefer a more interactive tour of the new features mentioned in the post, check out the video below:

Acknowledgements

Thank you to all the contributors (list below is based on GitHub usernames):

JupyterLab: @Adam-D-Lewis @afshin @ajbozarth @AmberArr @andrewfulton9 @andreytaboola @andrii-i @bollwyvl @brichet @Carreau @claytonparnell @cmarmo @Darshan808 @davidbrochart @deephbz @dlqqq @echarles @fcollonval @fleming79 @holzman @hxrshxz @ianthomas23 @iisakkirotko @itsmevichu @JasonWeill @jesuino @joaopalmeiro @jtpio @kellyrowland @krassowski @kuraga @maitreya2954 @martenrichter @martinRenou @mgeier @MUFFANUJ @nkn2022 @Nriver @pawel99k @pdarshane @peytondmurray @pre-commit-ci @Princekumarofficial @Rishab87 @rpwagner @RRosio @rsaditya01 @SamuelMarks @SatyajitRedekar @SylvainCorlay @trungleduc @Zsailer
Notebook: @andrii-i @jdavid @jtpio @krassowski @RRosio

Special thank you to all the new contributors, the Jupyter Frontends team hopes to see you back!

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab, Notebook and JupyterLab Desktop issues: @krassowski, @RRosio, @andrii-i, @danyeaw among others who attend.

Building AI Agents for JupyterLab using Notebook Intelligence

2025-02-24T18:03:00+00:00

Please note that this is not an official Jupyter subproject but an independent open-source tool for JupyterLab users who want to use GitHub Copilot as an AI coding assistant.

Notebook Intelligence (NBI) is an AI coding assistant and extensible AI framework for JupyterLab. (For an introduction to NBI see Introducing Notebook Intelligence and for basics of extending NBI see Building AI Extensions for JupyterLab blog posts.)

GitHub Copilot and other AI coding assistants are great at generating code and answering coding related questions. But they can do a lot more than generating text and code thanks to LLM features such as tool calling and AI agents. NBI provides an extensible AI framework to integrate tool calling and AI agents into JupyterLab Copilot Chat.

AI Agent extension example

What is tool calling and an AI Agent?

Tool calling is a feature of LLMs. It lets you introduce your own functions to LLM so that they can be called in response to chat prompts. LLM can convert natural language prompts to function calls with arguments. Tool calls are executed on the client side (i.e. Jupyter server) by your extension and only the function schema is provided to the LLM. Tool calling lets LLM interact with real time data, proprietary or external apps and services.

AI Agents are collections of tools that can run tasks on behalf of the user. Given a natural language prompt, LLMs can reason, create an execution plan and call multiple tools in a chain. NBI provides a framework to build these type of AI Agent integrations and handles the orchestration between LLMs and your tools.

AI Agent Extension Example

Let’s build an AI Agent for JupyterLab using Notebook Intelligence extension APIs. (The full source code for this extension is available here.) This will be an AI agent for map creation and notebook sharing. It will have the following capabilities:

Looking up geo-coordinates for an address
Showing maps centered at an address in the Copilot Chat UI
Creating notebooks that show maps centered at specified addresses
Sharing notebooks publicly using notebooksharing.space

The tasks above will be run by the AI Agent in response to natural language prompts by the user.

For this extension we will build four tools that will be integrated into JupyterLab Copilot Chat, for each of the tasks above. Tools are defined as classes derived from NBI Tool abstract class. A tool needs to implement the methods and properties defined in this base class.

Tool class provides the metadata information for the tool and implements the pre_invoke and handle_tool_call methods. pre_invoke method is called right before handle_tool_call with the tool arguments and it gives an opportunity for the tool to prompt for confirmation of the tool execution.

schema property of the Tool is the function schema based on OpenAI’s function calling schema. It lets you describe your function and its parameters as an object. A Tool is expected to return an object as response from the handle_tool_call method call.

Geo Coordinates Lookup Tool

This tool looks up geo-coordinates for an address using Nominatim library. pre_invoke method for this tool only shows a message in Chat UI before looking up for the geo-coordinates in handle_tool_call method.

class GeoCoordinateLookupTool(Tool):
    @property
    def name(self) -> str:
        return "geo_coordinate_lookup"

    @property
    def title(self) -> str:
        return "Get geo-coordinates from an address"
    
    @property
    def description(self) -> str:
        return "This is a tool that converts an address to a geo-coordinates"
    
    @property
    def schema(self) -> dict:
        return {
            "type": "function",
            "function": {
                "name": self.name,
                "description": self.description,
                "parameters": {
                    "type": "object",
                    "properties": {
                        "address": {
                            "type": "string",
                            "description": "Address to convert to geo-coordinates",
                        }
                    },
                    "required": ["address"],
                    "additionalProperties": False,
                },
            },
        }

    def pre_invoke(self, request: ChatRequest, tool_args: dict) -> Union[ToolPreInvokeResponse, None]:
        address = tool_args.get('address')
        return ToolPreInvokeResponse(
            message=f"Getting coordinates for '{address}'"
        )

    async def handle_tool_call(self, request: ChatRequest, response: ChatResponse, tool_context: dict, tool_args: dict) -> dict:
        address = tool_args.get('address')
        location = geolocator.geocode(address)
        return {"latitude": location.latitude, "longitude": location.longitude}

Get geo-coordinates tool

Map Response Generator Tool

This tool shows a map in Copilot Chat UI centered at geo-coordinates. In pre_invoke method this method only shows a notification message in Chat UI. In handle_tool_call method, this tool returns a HTMLFrame response that uses HTML to show a map centered at the requested location using Google Maps.

class MapResponseGeneratorTool(Tool):
    ...

    def pre_invoke(self, request: ChatRequest, tool_args: dict) -> Union[ToolPreInvokeResponse, None]:
        geo_coordinates = tool_args.get('geo_coordinates')
        latitude = geo_coordinates.get('latitude')
        longitude = geo_coordinates.get('longitude')
        return ToolPreInvokeResponse(
            message=f"Showing a map centered at latitude: {latitude} and longitude: {longitude}"
        )

    async def handle_tool_call(self, request: ChatRequest, response: ChatResponse, tool_context: dict, tool_args: dict) -> dict:
        geo_coordinates = tool_args.get('geo_coordinates')
        latitude = geo_coordinates.get('latitude')
        longitude = geo_coordinates.get('longitude')

        response.stream(HTMLFrameData(f"""<iframe width="100%" height="100%" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" id="gmap_canvas" src="https://maps.google.com/maps?width=400&amp;height=400&amp;hl=en&amp;q={latitude},{longitude}&amp;t=&amp;z=11&amp;ie=UTF8&amp;iwloc=B&amp;output=embed"></iframe>""", height=400))
        response.finish()

        return {"result": "I showed the map"}

Below is an example prompt showing map centered at “Golden Gate Bridge, San Francisco”. Note that an address was provided to Copilot as the input but Map Response Generator Tool accepts only geo-coordinates as input. This is where LLM automatically decided that it needs to first call the Geo Coordinates Lookup Tool to get geo-coordinates for this address and then it called the Map Response Generator Tool with the geo-coordinates. LLM automatically chained multiple tools and NBI handled this chaining to get the correct response for the user’s prompt.

Map Response Generator Tool

Map Notebook Creator Tool

This tool creates a notebook centered at the specified geo-coordinates. In pre_invoke method this method only shows a notification message in Chat UI. In handle_tool_call method, the tool creates a notebook using nbformat library, saves it to disk and then opens the notebook in JupyterLab UI using the response.run_ui_command NBI method.

class MapNotebookCreatorTool(Tool):
    ...

    def pre_invoke(self, request: ChatRequest, tool_args: dict) -> Union[ToolPreInvokeResponse, None]:
        geo_coordinates = tool_args.get('geo_coordinates')
        latitude = geo_coordinates.get('latitude')
        longitude = geo_coordinates.get('longitude')
        return ToolPreInvokeResponse(
            message=f"Creating a map notebook for latitude: {latitude} and longitude: {longitude}"
        )

    async def handle_tool_call(self, request: ChatRequest, response: ChatResponse, tool_context: dict, tool_args: dict) -> dict:
        geo_coordinates = tool_args.get('geo_coordinates')
        latitude = geo_coordinates.get('latitude')
        longitude = geo_coordinates.get('longitude')

        now = dt.datetime.now()
        map_file_name = f"map_{now.strftime('%Y%m%d_%H%M%S')}.ipynb"

        nb = nbf.v4.new_notebook()
        header = """\
        ### This map notebook was created by an AI Agent using [Notebook Intelligence](https://github.com/notebook-intelligence)
        """

        install_code_cell = "%%capture\n%pip install folium"

        map_code_cell = f"""\
        import folium

        map = folium.Map(location=[{latitude}, {longitude}], zoom_start=13)
        map"""

        nb['cells'] = [
            nbf.v4.new_markdown_cell(header),
            nbf.v4.new_code_cell(install_code_cell),
            nbf.v4.new_code_cell(map_code_cell)
        ]
        nb.metadata["kernelspec"] = { "name": "python3"}
        nbf.write(nb, map_file_name)

        await response.run_ui_command("docmanager:open", {"path": map_file_name})

        return {"result": "I created and opened the map notebook"}

Map Notebook Creator Tool

This tool shares a notebook publicly by uploading it to notebooksharing.space and displays the link to the shared notebook.

In the pre_invoke method implementation, this tool asks for confirmation first as this operation is an undoable share of the notebook publicly. Only after the user confirms, handle_tool_call is executed. In handle_tool_call method the tool uploads the notebook at the notebook_file_path using nbss_upload library and then shows the link to the shared notebook on notebooksharing.space.

class NotebookShareTool(Tool):
    ...
    
    def pre_invoke(self, request: ChatRequest, tool_args: dict) -> Union[ToolPreInvokeResponse, None]:
        file_path = tool_args.get('notebook_file_path')
        file_name = path.basename(file_path)
        return ToolPreInvokeResponse(
            message=f"Sharing notebook '{file_name}'",
            confirmationTitle="Confirm sharing",
            confirmationMessage=f"Are you sure you want to share the notebook at '{file_path}'? This will upload the notebook to public internet and cannot be undone."
        )

    async def handle_tool_call(self, request: ChatRequest, response: ChatResponse, tool_context: dict, tool_args: dict) -> dict:
        file_path = tool_args.get('notebook_file_path')
        file_name = path.basename(file_path)
        share_url = nbss_upload.upload_notebook(file_path, False, False, 'https://notebooksharing.space')
        response.stream(AnchorData(share_url, f"Click here to view the shared notebook '{file_name}'"))

        return {"result": f"Notebook '{file_name}' has been shared at: {share_url}"}

Notebook Share Tool

Tool call schema definitions

It is important to define schemas of the tools clearly and disambiguate the tools as much as possible so that the LLM can invoke the proper tool based on the user prompt. LLM parses the user prompt, decides which tools to call and generates the input parameters for the call.

If current file or selection is made visible by the user, NBI can provide the file paths and content as context to the LLM. That way LLM can use those as additional context for a tool call. That is how Notebook Share Tool was able to access the current notebook file.

Tool chaining

After parsing the user prompt, LLM creates an execution plan and can call multiple tools in a chain. NBI handles this tool chaining for you. It is important to define your schemas with the chaining in mind. Consider defining matching tool outputs and inputs so that the output of a tool can be passed onto another one directly if needed.

Notice that in this extension example MapResponseGeneratorTool and MapNotebookCreatorTool both take in geo_coordinates (latitude, longitude) as input and GeoCoordinateLookupTool outputs geo_coordinates. This lets LLM to directly pass the output of GeoCoordinateLookupTool to MapResponseGeneratorTool and MapNotebookCreatorTool. It also lets a user to use an address to trigger MapResponseGeneratorTool and MapNotebookCreatorTool, because LLM knows that there is another tool it can call to generate input (geo_coordinates) from address for these tools.

Chat Participant

In NBI AI framework, AI Agents are defined as chat participants and tools are tied to specific chat participants. For our extension we create AIAgentChatParticipant as our participant (for more details on NBI extensions and chat participants see this blog). Our chat participant returns list of tools it defines from the tools property.

In handle_chat_request method our chat participant passes the request to the base ChatParticipant class to handle tool calling for us.

class AIAgentChatParticipant(ChatParticipant):
    @property
    def id(self) -> str:
        return "ai-agent"
    ...
    
    @property
    def tools(self) -> list[Tool]:
        return [GeoCoordinateLookupTool(), MapResponseGeneratorTool(), MapNotebookCreatorTool(), NotebookShareTool()]

    async def handle_chat_request(self, request: ChatRequest, response: ChatResponse, options: dict = {}) -> None:
        ...
        await self.handle_chat_request_with_tools(request, response, options)

NBI Extension

Finally we create our NBI extension class AIAgentExtension. This class basically registers our chat participant to NBI on extension activation.

class AIAgentExtension(NotebookIntelligenceExtension):
    ...

    def activate(self, host: Host) -> None:
        self.participant = AIAgentChatParticipant(host)
        host.register_chat_participant(self.participant)
        log.info("AI Agent example extension activated")

That is all there is to create an AI Agent for JupyterLab using Notebook Intelligence. The full source code for this example is available along with installation instructions for you to use as a reference and/or build on top.

I am looking forward to seeing the AI Agents built by the community. Please try the extension APIs and share your feedback using project’s GitHub issues! User feedback from the community will shape the project’s roadmap.

About the Author

Mehmet Bektas is a Senior Software Engineer at Netflix and a Jupyter Distinguished Contributor. He is the author of Notebook Intelligence, and contributes to JupyterLab, JupyterLab Desktop and several other projects in the Jupyter eco-system.

Introducing Notebook Intelligence!

2025-01-13T16:28:00+00:00

Please note that this is not an official Jupyter subproject but an independent open-source tool for JupyterLab users who want to use GitHub Copilot as an AI coding assistant.

I am thrilled to announce the release of Notebook Intelligence (NBI)! NBI is an AI coding assistant and extensible AI framework for JupyterLab. It uses GitHub Copilot under the hood and is inspired by its design principles. NBI greatly boosts the productivity of JupyterLab users with AI assistance powered by GitHub Copilot.

Generate code

Generate code, iterate on it

NBI integrates tightly with the notebook document. Using cell toolbar item “Generate code” or keyboard shortcut “Cmd + G” / “Ctrl + G”, you can launch the inline coding assistant popover to generate code cells.

Generate code popover

If the inline coding assistant is launched for a cell with existing code, then the generated code is shown in a diff view for approval.

Generate code with diff viewer

If you are not satisfied with the generated code, you can re-generate with an updated prompt. Diff viewer also lets you edit the generated code manually before accepting it.

Fix code in cell with NBI

Explain and fix code, troubleshoot errors reported

NBI adds a new sub menu to notebook cell context menu. Copilot can explain code in a cell or suggest fixes for any issues in it. Clicking these menu items opens Copilot Chat and generates a suggestion.

Copilot context menu

If the code cell has an output you can ask Copilot to explain it. If there are any errors reported, you can have Copilot to troubleshoot as well. These actions also take you to Copilot Chat interface.

Explain, fix, troubleshoot

Inline Completions

Notebook Intelligence integrates with JupyterLab’s inline completion APIs and provides code suggestions as you type in a code cell or a Python file.

Inline completions

Code suggestions are generated using GitHub Copilot. They are blazing fast and relevant to document you are working on. In addition to the code cell you are working on, the code in the surrounding cells are also used as context when generating suggestions.

Inline completions example

Copilot Chat

NBI provides a user friendly chat interface to chat with GitHub Copilot. You can ask questions related to coding.

Copilot Chat

If Copilot generates code snippets, they are rendered in a special format in a section with an action toolbar. Toolbar will have buttons to copy, insert, create new Python file and notebook from the snippet. Using these you can easily integrate the generated code into your project.

Copilot chat toolbar actions

Chat Commands

Chat interface also provides commands to generate new notebooks and Python code files based on your task described in the prompt. Commands start with “/” and a command auto-complete list is shown as you type. You can navigate between the commands using keyboard and choose a suggestion using “Enter” or “Tab” keys.

Chat command auto-complete

/newNotebook command

You can generate new notebooks from a prompt with the /newNotebook command. Notebook generation is shown interactively, a new empty notebook is created and opened, then code and markdown cells are added onto the notebook as they are generated by NBI and GitHub Copilot.

Generate notebook example

/newPythonFile command

You can also create new Python files from a prompt using the /newPythonFile command.

Generate Python file example

Getting Started with Notebook Intelligence

Notebook Intelligence is a JupyterLab extension published as a Python package. Simply install the package and restart JupyterLab. NBI will add a new sidebar item for Copilot Chat, a notebook context sub-menu, a cell toolbar item for “Generate code” and a status bar item for GitHub Copilot login status to JupyterLab UI. It will also be integrated with inline completion (AI suggestions for code completion).

pip install notebook-intelligence

Authentication with GitHub Copilot

Notebook Intelligence requires a GitHub Copilot subscription. NBI provides a user friendly interface to sign into your GitHub Copilot account from JupyterLab UI to activate access to your subscription.

GitHub Copilot authentication

Extensible Framework

Notebook Intelligence provides APIs to let developers extend its capabilities. You can add custom agents / chat participants, define tools (function calling) and add RAG capabilities to provide your own context to LLM for code / chat response generation. Stay tuned for my next blog post where I will walk you though extensibility features.

Notebook Intelligence is currently in beta and designed for Python (support for more languages coming soon). Please try it out and share your feedback and any feature requests using project’s GitHub issues! User feedback from the community will shape the project’s roadmap.

About the Author

JupyterLab 4.3 and Notebook 7.3 are available!

2024-12-05T22:41:00+00:00

JupyterLab 4.3.0 has been released! This new minor release of JupyterLab includes 1 new feature, 42 enhancements, 62 bug fixes, 48 maintenance tasks and 35 documentation improvements. There were 38 contributors to this release including 18 new contributors to JupyterLab.

Jupyter Notebook 7.3.0 has also been released, including many of the fixes and enhancements in this JupyterLab 4.3.0 release. While the releases on GitHub provide additional detail on the updates made to both JupyterLab 4.3 and Notebook 7.3, this article highlights some particularly notable changes.

Extension authors can refer to the Extension Migration Guide for information on API updates and details regarding changes to core packages.

Minimap

The virtual scrollbar now acts as a minimap and exposes information on whether a cell:

is running/scheduled ([*]), idle ([ ]) or was already run (e.g. [1]),
was modified since it was last executed (“dirty”) — orange background,
has an output that contains an error — red background,
is markdown/code ([ ]/[*]/[1] for code, nothing for markdown),
an how much text/code it contains.

To enable the minimap, click on the hamburger icon (≡) which appears in the notebook toolbar. If you do not see the hamburger icon, go to Settings → Notebook → Windowing mode and choose “full”.

The notebook minimap in JupyterLab 4.3

Fullscreen mode

JupyterLab now offers two ways to toggle the full screen mode from within the application:

using the View → Appearance → Fullscreen Mode menu entry,
using a customizable shortcut, by default F11 (custom shortcuts are supported in Chrome, Safari and Edge).

File browser enhancements

The file browser now:

supports resizing the columns and remembers the column sizes after reloading JupyterLab,
supports uploading folders by drag-and-drop,
supports navigation with a single click (opt-in in JupyterLab, default in Jupyter Notebook),
has the file filter collapsed by default (funnel icon), increasing the space available.

File browser enhancements in JupyterLab 4.3

Server-side execution and collaboration

JupyterLab 4.2 added the option for extensions to implement server-side execution, which preserves outputs created when the browser window is closed or disconnected. The server-side execution builds on the same shared models API as the real-time collaboration (RTC).

You can try these features by installing extensions:

jupyter-server-nbmodel* provides server-side execution for jupyter-server,
jupyter-collaboration provides the real-time collaboration features,
jupyverse is an alternative server (a replacement for jupyter-server) which supports server-side execution.

* while jupyter-server-nbmodel is developed by maintainers of JupyterLab, as of the JupyterLab 4.3.0 release date it is not an official Project Jupyter extension.

Improved kernel and server interactions

The previous release enabled connecting to external kernels, such as those spawned by a third-party application like Blender. In this release the kernel selector dialog was improved to also show the external kernels.

The previous release improved the awareness of the kernel/kernel specification distinction by providing both tree and list view in the kernels sidebar panel, but only the tree view featured the kernel identifiers. In this release both the list and tree view show the kernel identifier stub.

A new toolbar button was added in the kernel allowing to shut down unused kernels (kernels with no widget attached).

Shut down unused kernels in JupyterLab 4.3

Full Width Notebook

In Jupyter Notebook 7.3, it is now possible to configure the notebook to take up the full width of the page via:

a setting that can be defined by a user via the Settings Editor
the View > Enable Full Width Notebook menu entry
the command palette, searching for Enable Full Width Notebook

Full width notebook in Jupyter Notebook 7.3

JupyterLab 3 end of maintenance

As a reminder, JupyterLab 3 will reach its end of maintenance date on December 31, 2024, anywhere on Earth. Users are highly encouraged to update to JupyterLab 4 as soon as possible.

For more information, please refer to the announcement post.

Acknowledgements

Thank you to all the new contributors, the Jupyter Frontends team hopes to see you back!

JupyterLab: @jgoodson, @Wzixiao, @krishanbhasin-px, @hnben, @sanskriti2005, @achhina, @mahendrapaipuri, @Renegade334, @Nazeeh21, @pauldruce, @EdsterG, @gderocher, @dhysdrn, @algonell, @nekomeowww, @mjpsyapse, @kaushalaaditya99, @Nagidrop
Notebook: @bluestealth, @andyscho, @algonell, @gjmooney

And thank you to returning contributors for their continued work!

JupyterLab: @afshin, @ajbozarth, @andrewfulton9, @andrii-i, @brichet, @cmarmo, @Darshan808, @davidbrochart, @fcollonval, @gabalafou, @HaudinFlorence, @itsmevichu, @JasonWeill, @joaopalmeiro, @jtpio, @krassowski, @maitreya2954, @Mehak261124, @NexVeridian, @RRosio
Notebook: @JasonWeill, @jtpio, @krassowski, @martinRenou, @RRosio

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab, Notebook and JupyterLab Desktop issues: @JasonWeill, @krassowski, @RRosio, @andrii-i among others who attend.

Exploring a Document’s Timeline in JupyterLab

2024-09-13T19:15:00+00:00

In collaborative environments, keeping track of changes and understanding the evolution of a document is crucial. This is especially true in fields like scientific computing and data science, where multiple contributors work together on complex projects. To address this need, we’re excited to introduce a document timeline component, a new feature that ships with the Jupyter Collaboration extension and enhances how teams interact with shared documents.

The timeline component is designed to give users control over a document’s history. Positioned as a slider in the JupyterLab status bar, it allows users to navigate through the timeline of a document. You can explore past versions, compare changes over time without altering the original document, and even restore specific versions. This feature is compatible with all types of shared documents within Jupyter, including notebooks, text files, and even third-party document types like JupyterCAD models.

Exploring the history of a Jupyter Notebook with the timeline component

How Does it Work ?

Co-editing of notebooks and other documents was introduced in JupyterLab 3.1 and has been improved and consolidated in subsequent releases. The feature can be enabled by installing the Jupyter Collaboration extension, which is built upon the Yjs framework, an implementation of CRDTs (Conflict-free Replicated Data Types). An important byproduct enabling real-time collaboration was the introduction of a journal of updates capturing all changes made by collaborators, which we leveraged to implement document timeline navigation.

Two key changes to Jupyter collaboration underlie the timeline component:

The ability to fork the document history, which is required to visualize the past state of the document without altering it.
The support of Undo/Redo operations in the Python implementation of Yjs, PyCRDT, through the implementation of an undo manager. While this was already available in Yjs, it was missing in PyCRDT until now.

As you move the slider to go back in time, the first operation that takes place is forking the document. Forking creates a new branch of the document at the selected point in history. This approach ensures that the most recent version of the document remains unaltered while you explore earlier versions. The forked version essentially acts as a sandbox where you can navigate through the document’s history, test out changes, and decide on the best course of action without modifying the main document.

When you navigate through the document’s timeline using the slider, the undo manager allows you to reverse or reapply any series of changes, stepping back through the document’s history without losing any information. If you decide to move forward again, the undo manager reapplies those changes in the exact order they were originally made, preserving the document’s integrity.

After reviewing the timeline, you can choose to restore a particular version at a selected timestamp. This restored version becomes the new active state of the document, effectively merging the changes from the forked branch back into the main document.

The document timeline component in the status bar offers an intuitive, flexible way to manage document history. Users can confidently experiment with different versions of their work, knowing that every action is reversible and that no progress will be lost. Whether you’re refining a piece of code, iterating on a design, or reviewing past contributions, the timeline equips you to iterate efficiently and effectively.

Seamless Integration with JupyterCAD

The document timeline is not just limited to text-based documents or notebooks. It was designed in a document-agnostic way, allowing its usage for any collaborative document. Consequently, it integrates seamlessly with JupyterCAD, JupyterLab’s extension for creating and manipulating 3D models. For engineers and designers, this integration is a game-changer.

In complex engineering projects, design iterations are common, and the ability to track the evolution of a 3D model is crucial. With the document timeline, users can effortlessly navigate through different stages of their design process. If a recent change in the 3D model doesn’t yield the desired results, the document timeline allows you to slide back to a previous version and pick up your work from there.

By combining the power of JupyterCAD with the document timeline’s history management, a team can achieve a more dynamic and flexible design process, ensuring that every idea is captured and every change is reversible. This integration exemplifies how the Jupyter Collaboration extension is enhancing not just collaborative editing but also specialized workflows in engineering and design.

Exploring the history of a JupyterCAD document with the timeline component

A New Era of Collaboration in Jupyter

The document timeline is a significant step forward in our ongoing work to make Jupyter a user-friendly platform for collaborative technical computing. By leveraging the advanced capabilities of the PyCRDT undo manager, we’ve created a tool that simplifies document history management and enhances the overall collaborative experience.

As we continue to innovate and expand the Jupyter Collaboration extension, we invite the community to try out the new document timeline feature and share their feedback. Together, we can further refine these tools and ensure that Jupyter remains at the forefront of collaborative computing, empowering users across all disciplines to achieve more.

Acknowledgments

The development of the document timeline and its integration into the Jupyter Collaboration extension has been a true team effort, made possible by the dedication and expertise of many individuals. Special thanks are extended to the following team members for their invaluable contributions:

David Brochart : For their innovative approach to integrating the undo manager within PyCRDT.
Afshin T. Darian : For their supervision and feedback, which have been crucial in refining the functionality of the timeline component.
Duc Trung Le : For their expertise in JupyterCAD and for ensuring that the timeline component seamlessly integrates with 3D model workflows.

About the Author

Meriem Ben Ismail just completed her Software Engineering degree at INSAT (National Institute of Applied Sciences and Technology in Tunisia) and her six-month internship as an open-source scientific software engineer at QuantStack.

JupyterLab 4.2 and Notebook 7.2 are available!

2024-05-22T21:00:00+00:00

JupyterLab 4.2.0 has been released! This new minor release of JupyterLab includes 3 new features, 20 enhancements, 33 bug fixes and 29 maintenance tasks. There were 39 contributors to this release including 10 new contributors to JupyterLab.

Jupyter Notebook 7.2.0 has also been released, including many of the fixes and enhancements in this JupyterLab 4.2.0 release. While the releases on Github provide additional detail on the updates made to both JupyterLab 4.2 and Notebook 7.2, this article highlights some particularly notable changes.

Extension authors can refer to the Extension Migration Guide for information on API updates and details regarding changes to core packages.

Easier Workspaces Management with GUI

It is now possible to manage workspaces from within JupyterLab with the workspaces graphical user interface. This long awaited feature offers users an additional way to interact with workspaces beyond the existing URL and CLI-based options, providing a more user-friendly and accessible alternative for some.

JupyterLab 4.2.0 Workspaces UI

Recently opened/closed files

Jupyterlab-recents, an extension for tracking recent files and directories has now been integrated into core JupyterLab. This extension adds a main menu entry for recently opened/closed files. JupyterLab users now have this native functionality that provides a quick reference to files they have recently worked with. Further development work in JupyterLab core now also allows users to search for and access recently closed files and folders through a modal via the shortcut Ctrl + Alt + A.

JupyterLab 4.2.0 Recently Closed Submodal

Full notebook windowing mode by default

The previously available full notebook windowing mode has now been made the default mode. This mode renders only the cells visible in the window, leading to improved performance. With this mode using the JupyterLab search function is recommended due to false negatives with the web browser’s native search functionality.

Improved Shortcuts Editor

Users can enjoy an improved experience when customizing shortcuts. Various improvements have been made to the shortcuts editor, namely: default shortcuts can be deleted, and shortcuts are sorted appropriately when using a language pack. Entries for shortcuts with varying arguments are also now accurately presented as separate items.

Modal option to delete shortcut key binding.

Dark High Contrast Theme

The JupyterLab Dark High Contrast Theme is now available for users who might benefit from higher contrast as outlined by the WCAG AAA accessibility standards for color contrast.

JupyterLab 4.2.0 Dark High Contrast Theme

Keyboard Shortcuts

The shortcuts extension received some improvements based on user feedback. The Ctrl + D shortcut has been restored to allow users to use to delete a line. In the interest of code editor compatibility the Ctrl + Shift + K shortcut can still be used for deleting lines and multi-cursor selection is now available via the default shortcut: Ctrl + Shift + D. Users are now able to toggle line comments with the shortcut Ctrl + / and toggle block comments with Alt + A, both of which are customizable via the Settings Editor. This release also addresses issues related to using various keys on international keyboards in macOS.

Acknowledgements

Thank you to all the new contributors, we hope to see you back!

JupyterLab: @linlol, @erkin98, @mdietz94, @UntitledError-09, @Susilkessav, @Tanmay-Deshmukh, @AnastasiaSliusar, @milinm, @Rob-P-Smith, @NexVeridian.
Notebook: @afeld

And thank you to returning contributors for their continued work!

JupyterLab: @davidbrochart, @fcollonval, @FoSuCloud, @JasonWeill, @jtpio, @krassowski, @Alanhou1222, @divyansshhh, @itsmevichu, @kolibril13, @sawickid, @andrii-i, @bollwyvl, @brichet, @Mehak261124, @e218736, @echarles, @gabalafou, @m158261, @afshin, @minrk, @RRosio, @trungleduc, @blink1073, @diyoyo, @AllanChain, @ericsnekbytes, @HaudinFlorence
Notebook: @jtpio, @krassowski

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab, Notebook and JupyterLab Desktop issues: @JasonWeill, @krassowski, @RRosio among others who attend.

Contributors to this blog post: @krassowski, @jtpio, @JasonWeill, @RRosio.

JupyterLab Desktop UI Modes

2024-03-11T21:09:00+00:00

We are pleased to announce UI Mode features recently added to JupyterLab Desktop (JLD). JupyterLab Desktop now provides a convenient way to set the JupyterLab UI layout per project and introduces an new layout mode: “Zen Mode”.

There is now a new sub-menu under session menu, titled “UI Mode”, which lets you change the UI layout mode. You can choose one of the pre-defined modes or leave the layout management to the web app.

UI Mode menu

If you select “Zen Mode”, “Single document IDE” or “Multi document IDE” for a project, UI layout will update to the selected mode and it will also be reset to this mode next time the project is opened. Even if you made modifications to the layout using JupyterLab View menu, UI layout will still reset when the project is reopened. You can choose “Managed by web app” option if you would like the selections on View menu to persist.

“Reset to session default” option resets the UI mode to either to default of “UI Mode for opening a single file” or “UI Mode” as defined in the settings dialog (described in UI Mode configuration below) based on the number of files opened by the session.

Multi document IDE mode

This mode is the default layout mode in JupyterLab web app. Activity bar and side bar on the left, activity bar on the right and status bar are visible in this mode. Multiple documents and terminals can be opened at the same time.

Multi document IDE mode

Single document IDE mode

This mode corresponds to the “Simple Interface“ mode in JupyterLab web app. Activity bar, side bar and status bar visibilities are the same as “Multi document IDE” mode but tab bar is not shown and only one document or terminal can be open at a time.

Single document IDE mode

Zen Mode

“Zen Mode” is a newly introduced mode in JLD which simplifies “Simple Interface” further by hiding activity bars, side bars and status bar. Zen Mode is great for focusing on a notebook document. It is the new default mode for opening a single notebook or creating a new notebook in JLD.

Zen Mode

Below is a demo of “Zen Mode” in action. Notice that using menus or keyboard shortcuts you can still very easily navigate between different notebooks and terminals.

Zen Mode demo

UI Mode configuration

Default UI Mode for sessions and for opening a single notebook can be configured from the Settings dialog as shown below. Setting both options to “Manage by web app” makes JLD behave the same as the JupyterLab web app.

UI Mode configuration

Try the latest JupyterLab Desktop and share your feedback with us using project’s GitHub issues! User feedback from the community shapes the project roadmap.

For more information and updates on the project, follow us on GitHub and Jupyter Blog.

About the Author

Mehmet Bektas is a Senior Software Engineer at Netflix and a Jupyter Distinguished Contributor. He maintains and contributes to JupyterLab, JupyterLab Desktop and several other projects in the Jupyter eco-system.

Python environment management using JupyterLab Desktop CLI

2024-03-01T20:41:00+00:00

JupyterLab Desktop (JLD) CLI provides several commands and options to manage Python environments for use in the application. In my previous blog post I had covered using JLD UI to manage Python environments. You can use jlab CLI commands to do the same and for additional environment management options.

Setting up jlab CLI

JupyterLab Desktop installers for Windows and Linux create jlab CLI command as part of the installation process. On macOS, the CLI command is created at first program launch. Since this requires elevated user permissions, users may need to do a one time manual approval on macOS UI. Visit Settings dialog on macOS to verify that CLI command is installed properly.

jlab CLI status on Settings dialog

Setting up CLI is only an operation to configure the command for use in the Terminal. It doesn’t install any additional software, the functionality is already built into the desktop app.

jlab env CLI commands

“jlab env [options]” CLI commands provide environment management functionality. Below are the list of actions supported with overview of each one. Each action can have a variety of parameter options. See the Python environment management CLI documentation on JLD GitHub repo for the details on parameter options.

Under the hood, these commands use conda and pip that are available on your system. conda and pip could be pre-installed or they become available with the bundled Python environment installation.

jlab env info

This command prints app’s Python environment configuration on the system. JLD initializes this config at launch time by discovering the Python configuration on your system. These settings can be updated by using the UI or CLI commands that are listed below.

jlab env info command output

jlab env list

Lists discovered and user set Python environments available to the app. Python paths, python and jupyterlab package versions and whether it was created by JLD are also listed.

jlab env list command output

jlab env create

Creates a new Python environment and adds to the application registry, making it ready to use by the app. Environments can be created by using the bundled environment installer or by downloading packages from registry. “jupyterlab” Python package is required for compatibility with JLD and it is automatically installed in most cases. Additional Python packages and conda channels to use can also be specified.

This CLI command provides more options compared to Python environment management UI. Additional environment sources can be used. You can create an environment from a pre-archived conda-pack bundle, conda-lock file or a conda environment file in addition to options available on the UI. These source files can be local file paths on the system or remote URLs.

Using remote sources, environments can be created using archives and environment definition files created by conda-store and similar tools.

Additional list of packages can be installed on top of packages defined in an environment definition file. Below is an example of creating a numpy environment using a remote environment definition file and installing scikit-learn in addition.

jlab env create commad example

jlab env activate

Activates a Python environment in system Terminal. Environments can be activated by name or full prefix path.

jlab env set-python-envs-path

Sets Python environment install directory used when creating new environments.

jlab env set-conda-path

Sets the base conda executable path. Base conda executable is used when creating new conda environments, and running conda commands by the app.

jlab env set-conda-channels

Sets conda channels to use when installing new conda packages.

jlab env set-system-python-path

Sets Python executable path to use when creating new venv environments.

jlab env update-registry

Updates the app environment registry. This command checks all the environments registered for compatibility and fetches Python and jupyterlab versions. This action is normally done at desktop app launch.

Setting project Python environments using CLI

You can set the Python environment used for a project very easily by using the Python environment selection popup on the UI. You can also set it by using the CLI command “jlab config set”.

Below is an example command to set a project’s Python environment using jlab CLI.

jlab config set commad to set project Python path

Additional resources

For additional details on environment management CLI commands see the Python environment management CLI documentation at JupyterLab Desktop GitHub repo. Command parameters and options with plenty of examples can be found there.

JLD provides other CLI commands to launch and configure the application. Check out the CLI documentation for other available commands.

Try the latest JupyterLab Desktop and share your feedback with us using project’s GitHub issues! User feedback from the community shapes the project roadmap.

For more information and updates on the project, follow us on GitHub and Jupyter Blog.

About the Author

JupyterLab 4.1 and Notebook 7.1 are here 🎉

2024-02-26T22:57:00+00:00

JupyterLab 4.1 and Notebook 7.1 are now available! These releases include several new features, bug fixes, and enhancements for extension developers. This release is compatible with extensions supporting JupyterLab 4.0 and Notebook 7.0.

JupyterLab 4.1 is one of the largest minor releases of JupyterLab to date, bringing 6 new features, 39 enhancements, and 114 bug fixes to users, and addressing 140 maintenance tasks. Project Jupyter thanks the 70 contributors, including 13 new code/documentation contributors, who helped us build this new version.

Jupyter Notebook 7.1 is the first minor release after the transition to the new codebase, which re-uses JupyterLab components. As such, Notebook 7.1 inherits many of the new features and fixes from JupyterLab 4.1. Feature parity with Notebook 6 was also improved in this release.

JupyterLab Desktop was also upgraded to version 4.1, receiving additional bug fixes and enhancements. Thank you to Mehmet Bektas for your continuing work to improve JupyterLab Desktop!

Extension authors should consult the Extension Migration Guide, which lists deprecations and changes to the public API.

Custom CSS

JupyterLab now supports automatic loading of custom CSS. Themes are the recommended way for customizing the JupyterLab look and feel, while custom CSS is intended for minor personal adjustments.

To opt in, start JupyterLab with the — custom-css flag. The location of the custom.css file is documented in the section on customizing the user interface. Please note that the CSS selectors may vary between versions and applications (JupyterLab vs Notebook).

Diagrams in Markdown

Matching GitHub-Flavoured Markdown, JupyterLab and Notebook now support Mermaid diagrams. To create a Mermaid diagram, use the mermaid language specifier for a code block in a markdown cell or document, for example:

```mermaid
flowchart LR

A[Hard] -->|Text| B(Round)
B --> C{Decision}
C -->|One| D[Result 1]
C -->|Two| E[Result 2]
```

which renders as:

Inline code completion

JupyterLab and Notebook now support automatic code (and text) completion presented as ghost text in the cell and file editors, allowing generative AI models to provide multi-line completions. The suggestions are provided by plugins implementing the IInlineCompletionProvider API. By default a single provider using the user’s kernel history is available.

The suggestions can be invoked as-you-type or manually using a configurable shortcut (by default Alt + ). The default keyboard shortcuts are displayed in the small widget shown when hovering over the ghost suggestion.

To enable the inline suggestions based on the kernel history, go to Settings → Settings Editor → Inline Completer → History provider → check the “enabled” checkbox.

In addition to the built-in history suggestions, additional inline completion providers can be installed. For example, the jupyter-ai extension, version 2.10.0 and newer, provides suggestions from compatible large language models.

The Inline Completer API is still considered experimental and may be subject to change. Please share your feedback!

Numerous improvements to keyboard navigation with focus on accessibility and usability are included in this release:

the notebook cells now retain focus
the focus can now be moved beyond the active notebook
the toolbars can now be navigated using arrow keys

For more details, see the post on the Jupyter Blog about keyboard navigation improvements.

Execution history in notebook

The code from previously executed cells can be used to populate empty cells, letting users iterate on code from previous cells or even previous sessions, depending on how a specific kernel stores its history.

To cycle between history items, press Alt + Arrow Up and Alt + Arrow Down.

To enable execution history, go to Settings Editor → Notebook → check the “Kernel history access” checkbox.

This feature was already available in the console in previous releases; it only works with kernels supporting execution history requests. To clear the execution history, consult the documentation of the kernel you are using (e.g., IPython/ipykernel).

Opening files from tracebacks

Paths to code files detected in error tracebacks are now turned into links. These links will open the corresponding file for editing, if it is in the Jupyter root directory, or they will open a read-only preview if the file is outside of the root directory and the active kernel supports the debugger.

Error indicator in the table of contents

When a cell fails during execution, an error indicator will be displayed by the corresponding heading, increasing awareness of the notebook state and enabling users to quickly navigate to the cell which requires attention.

Plugin Manager

Individual plugins can now be disabled or enabled from a new Plugin Manager user interface. While the existing extension manager can enable/disable entire extensions, each extension is composed of one or more plugins (and plugins form the basis of JupyterLab itself) thus the plugin manager enables more extensive customization of the JupyterLab experience in addition to the previously available extension manager.

This feature is intended for advanced users and is documented in depth in the documentation.

Administrators may want to lock specific plugins if they are required for any reason; this will prevent users from disabling the plugins via Plugin Manager and remote API calls. The Plugin Manager itself can be disabled using the CLI.

Virtual scrollbar for notebook in windowed mode

The windowed notebook now has an optional scrollbar that shows the active cell and selected cells. Users can jump to a specific cell.

To enable the virtual scrollbar, go to Settings → Notebook → Windowing mode, choose “full”, and click on the hamburger icon (≡) which appears in the notebook’s toolbar.

Virtual scrollbar is an experimental feature. Please share your feedback!

Notifications

JupyterLab 3.6 added a notification center which so far was only used for announcements and version update notifications (both opt-in). JupyterLab 4.1 adds two notifications to guide users in potentially confusing situations:

when a user attempts to save a read-only document, a transient notification suggesting using “save as” is displayed
when a user attempts to execute a cell before a slow-starting kernel has initialized, a notification is shown to indicate that the cell cannot be yet executed (this is opt-in and needs to be enabled in settings)

Full notebook windowing mode improvements

Notebooks in the full windowing mode only render the visible cells, significantly improving the performance of the application. Numerous improvements for the full windowing mode behavior (such as scrolling, search, rendering, and navigation) are included in this release (see the list of issues in #15258 for details). Note: the windowing mode is still experimental and known issues remain to be solved.

Search improvements

The search box will now grow automatically to accommodate longer text
Search in selection can now be toggled using Alt + L and automatic search in selection can be configured in settings
Tooltips with shortcuts were added to the buttons in the search box to improve discoverability of the shortcuts

Acknowledgements

Special shout out to new code/documentation contributors (hope to see you again!):

JupyterLab: @alden-ilao @AllanChain @ashna1jain @brijsiyag @DcWire @DenisaCG @Deepali1211 @dhml @dolevf @eliaslma @emmanuel-ferdman @e4e @g547315 @jans-code @j264415 @kiliansinger @KiranmaiKalla @misterfads @mmichilot @mdengler @MFA-X-AI @m158261@nbowditch-einblick @nluetts @paolocarinci @pauky @paulkim3151 @phil-zxx @Rmarieta @RRosio @Sarthug99 @sinistersnare @t03857785 @Wh1isper
Notebook: @Dilip-Jain @haok1402 @akx

Thank you to the returning contributors (please do feel invited to review pull requests as well!):

JupyterLab: @afshin @akx @andrewfulton9 @andrii-i @bollwyvl @bikash30851 @brichet @davidbrochart @divyansshhh @dharmaquark @DonJayamanne @echarles @ericsnekbytes @fcollonval @firai @FoSuCloud @gabalafou @hbcarlos @JasonWeill @jtpio @krassowski @mctoohey @minrk @nishikantparmariam @parmentelat @skyetim @smacke @SylvainCorlay @telamonian @tibdex @timkpaine @trungleduc @yuvipanda
Notebook: @brichet @jtpio

and everyone who tested the pre-releases!

Additionally, we would like to thank our community triage leaders who helped sort issues for JupyterLab (@JasonWeill), Notebook (@RRosio) and JupyterLab Desktop during the course of weekly triage meetings.

Contributors to this blog post: @JasonWeill @krassowski @gabalafou @jtpio

Python environment management in JupyterLab Desktop

2024-02-19T22:26:00+00:00

We are pleased to announce Python environment management features recently added to JupyterLab Desktop (JLD). Now you can create new Python environments and manage existing ones on your system, right from JupyterLab Desktop UI.

Python environment management dialog

Python environments and their use in JupyterLab Desktop

The standard distribution of JupyterLab is a Web Application which is available as a Python package named “jupyterlab”. JupyterLab Desktop makes installing and launching JupyterLab much easier by bundling it together with Python and other scientific computing dependencies in the form of a Python environment.

Python environments provide isolation of package installations and they let you work on different projects with different set of packages and/or package versions. JLD comes with a bundled Python environment installer and lets users install it as the default environment for the app from the UI and effortlessly. It can also use existing Python environments on a system to launch JupyterLab web app.

JupyterLab Desktop — Python environment selection

With the latest updates, JLD supports creating custom Python environments from the UI and the CLI. Bundled environment can now be installed to multiple locations, as different virtual environments. JLD also allows you to create new environments by downloading packages from conda or PyPI registries.

Why support environment management in JupyterLab Desktop?

It is common for our users to use different Python environments for different projects as they may require different set of Python packages or package versions. Also, in order to use a Python environment in JLD, certain requirements need to be satisfied, such as existence of “jupyterlab” package. These are some of the motivations behind adding support for Python environment management to JupyterLab Desktop.

Normally, creating a Python environment requires installing Python and/or conda onto the system first and getting familiar with terminal commands required to manage the environments. JLD simplifies this process by eliminating the need to make additional installations and by providing a user friendly interface, making it possible to create new environments with few UI clicks.

conda and Python are shipped with JupyterLab Desktop within its bundled environment installer. Once the bundled environment is installed then JLD can use the bundled conda and Python to create new environments without requiring any further conda/Python installation from the user.

Python environments created in JLD are compatible with the application itself and they are added to the environment registry of JLD automatically for use in sessions. This prevents dealing with compatibility issues and manually adding environments to JLD registry.

Python environment management dialog

JupyterLab Desktop now has a new dialog which lets you manage Python environments and settings. You can access this dialog by clicking “Manage Python environments” menu item on session menu (hamburger menu on top-right).

Managing existing environments

“Environments” tab lists the environments discovered on your system. If you have other compatible environments available on your system but not discovered then you can add those by clicking “Add existing” button. You can choose the Python executable path in the system dialog that will be shown and the environment will be validated and added to JLD registry. Any validation errors will be shown above the environment list.

Python environment context menu

You can hover over the environment list to see additional details on the environment such as JupyterLab version. You can access actions for each environment by clicking the menu on the right end of the row. You can copy the Python path or detailed environment info to clipboard by using the first two menu items. Clicking “Launch Terminal” opens a system terminal and activates the selected environment. You can browse the environment’s file system by clicking “Reveal in Finder/Explorer” . “Delete” action is available for environments created by JLD. It lets you remove the environment installation from your system.

Creating new environments

“Create new” tab lets you create new environments using the bundled installer or packages from registry.

“Copy of the bundled environment” installs a copy of the bundled environment in a different location on your system. You can set a name for it and the installation path will be shown below. The parent directory for new environment installations can be configured as will be shown in the sections below.

Create new environment using bundled installer

“New environment” option lets you create a new environment from scratch by downloading packages from conda or PyPI registries based on your environment type selection. In order to be compatible with JLD, “jupyterlab” Python package is installed into the environment by default. You can uncheck “Include jupyterlab” if you don’t plan to use the environment with JLD. You can install additional Python packages into the environment using “Additional Python packages” field and by entering the list of packages separated by space. The preview of the environment create command will be shown below. You can click “Show output” during installation to see the progress or to inspect the output from installer.

Create new environment using packages from registry

Newly created environments will be listed in “Environments” tab and they will be available to use in JLD sessions immediately.

Python environment settings

“Settings” tab lets you set Python environment configuration for JLD. The settings on this dialog are auto populated based on defaults or information discovered on your system.

Python environment settings

The default Python environment to use for JLD can be set on the top. This setting used to be in the “Settings dialog” and moved here.

“New Python environment install directory” defines the parent directory for newly created environments.

“conda path” is the path of conda executable to use to create new conda environments and to activate conda sub environments.

“conda channels” sets the channels to use when installing conda packages.

Python path setting at the bottom controls which Python executable to use when creating new venv environments.

When local JupyterLab Desktop sessions are created, the active environment information is shown on top-right section of the title bar. This session info button is clickable and when clicked it shows the Python environment selection popup. New features are added to this popup with the latest release.

On top row of this popup, the current Python path used in the session is shown now. There are two new buttons on the right of this path. The first one lets you restart the JupyterLab server running for the session. This could be useful to restart JupyterLab web app after installing packages, without restarting the whole app. The second button lets you copy session information to the clipboard, such as the URL of the JupyterLab server running.

Session environment info and action buttons

Now you can filter the Python environments listed on the environment select popup. As you type into the path filter field, the environments will be filtered by the match in Python path.

Filter Python environments

Clicking the gear icon next to filter input field takes you to the Python environment management dialog.

Updating bundled Python environment installation

When JupyterLab Desktop is updated, the bundled Python environment installation is not updated automatically. There wasn’t a clear indication of this out of sync installation and users had to go to Settings dialog to manually update the bundled environment.

Now with the latest version, notification badge is shown when the environment update is available and auto-update of the bundled environment installation made possible. You can configure the environment update options on “Advanced” tab of the “Settings dialog”. Note that “Update bundled environment automatically when app is updated” option will delete the existing installation and make a fresh install of the bundled environment.

Bundled environment update settings

When there is an update available for the bundled environment installation a notification badge is shown on the session title bar with a red circle over the server icon.

Bundled environment update notification badge

Also, a new action button is shown on environment selection popup on the right of the current Python path label, in orange color. You can update the bundled environment installation by simply clicking this button.

Bundled environment update button

Bundled environment updates require app restart and update is installed before the next launch of the application.

Bundled environment update progress

Coming up next!

Stay tuned for my next blog post which will be on the Python environment management using JupyterLab Desktop CLI! CLI commands provide additional options for creating Python environments such as installation using environment definition files and conda-pack bundles.

Try the latest JupyterLab Desktop and share your feedback with us using project’s GitHub issues! User feedback from the community shapes the project roadmap.

For more information and updates on the project, follow us on GitHub and Jupyter Blog.

About the Author

JupyterLab 3 end of maintenance

2024-02-19T22:07:00+00:00

The JupyterLab Council has agreed to an important change to JupyterLab’s version lifecycle. Each major version of JupyterLab will now receive updates until one year after the following major version’s first release. JupyterLab 4.0.0 was released on May 15, 2023, so JupyterLab 3 will reach its end of maintenance date on May 15, 2024, anywhere on Earth. To help us make this transition, fixes for critical issues will still be backported until December 31, 2024. If you are still running JupyterLab 3, we strongly encourage you to upgrade to JupyterLab 4 as soon as possible.

This represents a change from JupyterLab’s previous policy, by which we supported two major versions of JupyterLab at a time, and which would have obligated us to continue supporting JupyterLab 3 until JupyterLab 5.0.0 became generally available. We decided to make this change to let developers, contributors, and users focus their attention on the newest major version, JupyterLab 4. Maintaining multiple major versions requires additional time and effort, which could instead be put towards making the current version better for all users. Recent releases on the 3.6.x branches have included mainly security fixes and maintenance fixes, not new features.

We recognize that there are many users still using JupyterLab 3, having downloaded it directly from package repositories or using it as distributed by a commercial vendor. We strongly encourage all users and vendors to upgrade to Lab 4 as soon as possible. If this is not possible, out of acknowledgement for the short notice of this announcement, we will consider pull requests addressing critical issues against the 3.6.x branch through December 31, 2024, anywhere on Earth, provided that they meet all of the following requirements:

The fix addresses a critical issue: a security vulnerability, data loss, or another issue of very high severity.
The fix includes tests, is reasonably small and low in complexity, and the author communicates actively with maintainers who review their work.
The fix is approved by a JupyterLab maintainer.

The JupyterLab team recognizes that a few regressions from JupyterLab 3 were present in JupyterLab 4.0.0; some of them are still open. Project Jupyter is driven by volunteers, community contributors, and support from individual and corporate users. We thank our community for their patience and we encourage our contributors to help us resolve bugs that block users from upgrading to the newer version. The JupyterLab maintainers are committing to review any pull requests submitted to address regressions as a priority over pull requests

We want to hear from you! If you have questions or comments about this new version lifecycle, please leave them below, or join the conversation on the Jupyter Community Forum. We also welcome discussion about the change at our weekly JupyterLab meetings, which are held every Wednesday at 09:00 US Pacific (17:00 UTC as of today, 16:00 UTC starting on March 10, 2024).

Thank you for using JupyterLab and for being a part of our great global community!

Recent keyboard navigation improvements in Jupyter

2023-12-16T09:48:00+00:00

Towards a more accessible Jupyter Notebook

Upcoming versions of JupyterLab (4.1.0) and Notebook (7.1.0) will include major keyboard accessibility fixes.

Keyboard accessibility is fundamental to overall app accessibility. Interactions that require pointing devices like mice or trackpads are usability barriers for many users across a wide spectrum of disabilities. Ensuring that all UI features are seamlessly accessible through keyboard-only navigation is imperative for an inclusive user experience.

A recent audit of the JupyterLab UI highlighted significant gaps in keyboard navigation, posing obstacles to usability and accessibility. One of the main obstacles to efficient keyboard navigation in JupyterLab is the number of UI items to skim through before being able to perform an action, such as typing in a document or creating a file. Indeed, as with any feature-rich application, the JupyterLab UI includes many menus, widgets, and inputs to interact with. The user interface is made of three main areas (left, center, and right), each one split into several panels. And most of these panels include toolbars with buttons to perform specific actions.

Improving this navigation required separate fixes for different elements of the page:

Menu bar (Lumino #465)
Tab bar (Lumino #612)
Toolbar (JupyterLab #15021)

All these changes follow the same logic: the Tab key is used to navigate between top-level elements (toolbar, menu, tab list), but not to navigate between items for which one should use arrow keys, nor to select an item for which one can use the Enter/Space keys. Most of these changes were actually applied to low-level components of JupyterLab, so that any JupyterLab extension built upon them will benefit from these improvements.

The changes to the toolbar make use of a new UI toolkit, based on web components, which natively includes these accessibility features, but also helps standardize the widgets used across the JupyterLab UI and JupyterLab extensions.

Notebook Tab Traps

Another blocker to keyboard navigation was the existence of “tab traps” or “focus traps” in the notebook widget. Tab traps occur when a user cannot move focus away from an interactive element with the Tab key.

The main problem was that, while the input area of each notebook cell could be reached by using the Tab key, the input area itself, which is a text editor, does not allow moving to the next item using the Tab key since the Tab key is used to insert spaces into the editor.

This has been fixed in JupyterLab PR #14115, by changing the tabbable items in the Notebook from the cell input to the cell itself. Now the Notebook follows the same logic mentioned above. Arrow keys are used to navigate the cells, whereas the Tab key is reserved mostly to navigate into and then back out of the Notebook. Entering or exiting the input element of the cell is done using the Enter and Escape keys, respectively.

These changes required a complete inversion in the way the keyboard events are handled in the notebook, especially with respect to keyboard shortcuts. These modifications were required to retain keyboard shortcuts in the output widget and at the notebook level, while changing the way element focus is managed in the notebook.

Future accessibility improvements

Accessibility work at Jupyter is grounded in the recommendations of the W3C Web Accessibility Initiative, in particular their standards for web content (WCAG), web apps (ARIA), and authoring tools (ATAG). There has been particular interest recently in addressing the authoring part of the equation.

That’s because a crucial aspect of the accessibility of notebooks lies in the content itself. It is imperative that Jupyter front ends actively support notebook authors in creating accessible content. This involves, for instance, prompting authors to include descriptive alt text for images, and issuing warnings when heading ranks are skipped. Skipping heading ranks can lead to difficulties in navigating the document outline, especially for users relying on screen readers. Such warnings could be brought through the language server protocol for markdown cells for example.

If your organization is interested in supporting such accessibility improvements, please reach out to the Jupyter accessibility team!

Feedback

Please try out the latest pre-release of JupyterLab 4.1. Try opening, editing, and saving a notebook without using your mouse or trackpad. Be aware that there are still areas of the UI as well as extensions that need fixing for mouseless use. We are keeping track of accessibility issues in a few places: JupyterLab GitHub accessibility label, Notebook 7 GitHub accessibility label, JupyterLab issue #9399. As you will find at those links, there’s still loads more to do. If you can help with either fixing those things or identifying other issues, please come help us, your contribution is valuable and you are welcome!

About the Authors

Nicolas Brichet is a scientific software developer at QuantStack, and a JupyterLab core team member. Prior to this work on keyboard navigation, Nicolas contributed to improving the accessibility of Jupyter by addressing the issues detected by the Axe accessibility testing engine.

Gabriel Fouasnon is a frontend developer at Quansight, a member of the Jupyter Software Steering Council representing the accessibility subproject, and a JupyterLab core team member.

Acknowledgments

This work on improving the keyboard navigation of JupyterLab was started with an audit of the keyboard navigation of the Jupyter Notebook v7 by Isabela Presedo-Floyd.

The work of Gabriel Fouasnon and Isabela Presedo-Floyd at Quansight on Jupyter accessibility was funded by the Chan Zuckerberg Initiative, through the “Essential Open Source Software for Science” (EOSS) grant program.

The work by Nicolas Brichet at QuantStack on the accessibility of Jupyter was funded by INSEE, the French National Institute of Statistics and Economic Studies.

We also want to acknowledge all of the members of the Jupyter Accessibility Council: Tania Allard, Alex Bozarth, Frédéric Collonval, Martha Cryan, Afshin T. Darian, R Ely, Tony Fast, Gabriel Fouasnon, Michał Krassowski, and Isabela Presedo-Floyd, without whom this work would not be possible.

A theme editor for JupyterLab

2023-06-19T08:11:00+00:00

JupyterLab is a comprehensive web user interface for scientific and technical computing providing tools such as notebooks, text editors, consoles, and terminals. Like many similar tools, it allows users to choose from light or dark color themes. However, users may want to further adjust the looks of the interface, just for fun or for specific personal preferences or needs.

The ability to fine-tune contrast, color palettes, and fonts can be very useful for accessibility, an essential requirement for software to be usable by the whole community. There is an ongoing project-wide effort to improve accessibility in Jupyter. Choices of color palettes impact color-blind users while font choices can have a significant impact on people affected by dyslexia, or who suffer from migraines.

This diversity of requirements and preferences shows that end users should have the means to adjust parameters and tweak existing themes. Subtle differences can improve comfort significantly.

JupyterLab themes

Theming in JupyterLab is enabled by the fact that most of the layout and colors of the UI are defined by a set of CSS variables. There is no need for a complete stylesheet: one can set values for the base parameters from which the appearance of the user interface is derived. This system ensures a consistent look and feel throughout the application.

Custom themes provide a set of values for the base CSS variables and package the resulting CSS file in JupyterLab extensions. A search on GitHub returns 29 repositories defining such custom themes for JupyterLab.

Creating a theme requires implementing values for dozens of base CSS variables. This is often achieved by theme authors tweaking the values given in the default dark or light themes.

Generating a consistent palette, testing, and packaging the outcome in the form of a JupyterLab extension requires development skills and is neither direct nor trivial.

A new tool for authoring JupyterLab themes

To lower the bar for customizing JupyterLab we created a new tool providing a simple interface for tuning the JupyterLab appearance interactively, allowing theme authors to:

use the selected colors in their application and “pin down” the result in the configuration,
export the outcome in a form amenable to packaging into a new JupyterLab theme.

The theme editor extension is a theme prototyping tool, a sandbox to test changes in colors, font family and font size, and a configuration tool for end users. It displays a reduced set of parameters one can play with, allowing users to select:

colors through color pickers,
numerical values from sliders (for font size, border radius and width),
font families from a predefined dropdown list.

A screenshot of JupyterLab with the theme editor panel is displayed in Figure 1, with a notebook opened in light theme. Figure 2 shows different screenshots with different custom themes.

Figure 1: The theme editor extension in JupyterLab.

Figure 2: Examples of dynamically editing the color and fonts scheme of JupyterLab with the theme editor.

Color palettes

For all the colors (accent, brand, border, error, info, layout, success, warn), the same logic is applied. The user picks a base color and a palette is automatically calculated using Microsoft’s fast-colors library.

Let’s take the specific example of the layout colors impacting the background of most elements of the interface. They are defined using — jp-layout-colori CSS variables from white to light grays (for the light theme).

- jp-layout-color0: white;
 - jp-layout-color1: white;
 - jp-layout-color2: var(-md-grey-200);
 - jp-layout-color3: var(-md-grey-400);
 - jp-layout-color4: var(-md-grey-600);

The number of colors in the palette fits the number of colors in the CSS set of variables (here the palette contains 5 colors). There are different ways to define colors (hexadecimal, RGBA, HSLA). The latter format has the advantage of giving direct access to luminance L, a measure of the lightness of a given color.

An inverse layout palette is computed for use with most text elements. The luminance of the inverse layout color L’ is calculated as 1-L plus a correction depending on how 1-L is close to 0.5. There isn’t a general CSS rule in JupyterLab concerning elements on top of a background but some PRs were proposed to reinforce the coupling between inverse layout elements and layout backgrounds with the same color index. The contrast still needs to be improved though, by using other palettes or better corrections when defining the inverse layout colors.

The full process just described from picking a layout color to resulting palettes and the corresponding interface is illustrated in Figure 3.

Figure 3: From a color to the layout, and inverse layout palettes with the resulting interface.

Font size and font family

As mentioned previously, font size and font family can be tuned too. Let’s take the example of the — jp-ui-font-size[i] CSS variables defining the text size of most of the text elements in the interface:

- jp-ui-font-scale-factor: 1.2;
 - jp-ui-font-size0: 0.8333em;
 - jp-ui-font-size1: 13px;  /* Base font size */
 - jp-ui-font-size2: 1.2em;
 - jp-ui-font-size3: 1.44em;

A slider lets the user control the base font size associated with — jp-ui-font-size1. The other font sizes are then calculated by applying a scale factor to the base font.

Concerning font families, a non-exhaustive list is proposed (i.e., default browser fonts or Google fonts). It includes both standard accessible fonts (Arial, Courier, Helvetica, Sans Serif, system-ui, Times New Roman, Verdana) and less usual ones to create artistic or special interfaces with cursive fonts ( for instance Dancing Script or Single Day). Only 2 fonts are proposed for code: Space Mono and monospace.

Storing the new theme

Once satisfied with a new theme, users can export it using a button at the top of the theme editor panel. This creates a variable.css file that can be packaged in a theme extension (see the extension template). The new parameters are also synchronously saved in the settings editor and can be restored for the next JupyterLab opening if the boolean useSettings is set to true. If not, the interface will look like in Figure 1: with light theme default CSS values. Resetting useSettings to true will restore the formerly tuned parameters.

Future development

The look and feel of the theme editor UI still needs to be improved. We will work on unifying the styling of all interfaces making use of react-jsonschema-form. It is already used for the JupyterLab settings editor, the notebook metadata editor of JupyterLab 4.0, and several extensions.

Moreover, the current implementation is bound to fast-colors palettes and we may want to use a different approach, like decoupling the layout and inverse layout palettes to reach better contrasts or give more freedom in the color choices.

Any help (e.g., filling issues for bugs or enhancement requests, opening pull requests) to improve the extension is welcome.

Try it out

You can install the PyPI package by running:

pip install jupyter_theme_editor

You can also try the theme editor on Binder.

Aknowledgement

Many thanks to Isabel Paredes for drawing the palette icon!

About the authors

Florence Haudin is a scientific software developer at QuantStack. She contributes to JupyterLab and to ipyleaflet.

Frédéric Collonval supervised this work as a technical director at QuantStack. He is a member of the JupyterLab core team and authored several JupyterLab extensions.

JupyterLab 4.0 is Here

2023-06-05T20:04:00+00:00

The Jupyter contributor community is proud to announce JupyterLab 4.0, the next major release of our full-featured development environment. The package is now available on PyPI and conda-forge. You can upgrade by running pip install --upgrade jupyterlab or conda install -c conda-forge jupyterlab. We have updated our JupyterLab Documentation for this new version.

Here are some of the major new features in JupyterLab 4.0, excerpted from our changelog:

JupyterLab is now faster, thanks to improvements such as CSS rules optimization, CodeMirror 6, MathJax 3, and notebook windowing. By rendering only the parts of a notebook that fit in the web browser viewport, JupyterLab 4 is much more efficient than JupyterLab 3 was when working with large notebooks.

There are additional performance improvements available via opt-in settings. You can help test them out by enabling them in your settings:

Faster tab-switching on Chromium browsers:
“Settings” → “JupyterLab Shell” → switch “Hidden mode” to “contentVisibility”
Better performance with long notebooks:
“Settings” → “Notebook” → switch “Windowing mode” to “full”

An upgraded text editor. CodeMirror, the text editor used for cells and file editors, has been updated to CodeMirror 6. This brings important accessibility and performance improvements as well as better customization capabilities. We have also improved the editor settings to be more powerful and more flexible.

We have moved real-time collaboration (RTC) into a separate package, jupyter_collaboration, version 1.0.0 of which is now available. Highlights include support for displaying multiple cursors and selections, and support for registration of new shared model types. If you’d like to use RTC in JupyterLab 4, please install the jupyter_collaboration package.

A new extension manager. In JupyterLab 4, the Extension Manager includes both prebuilt Python extensions and extensions from pypi.org. Installing from PyPI removes the need to build when installing an extension using the Extension Manager. Developers can provide an alternative package repository to display their own set of extensions.

Improved document search. The Search and Replace functionality has been improved with new features when searching in a notebook, including highlighting matches in rendered markdown cells, searching in the current selection, multi-line search, replacement using regular expression capture-group references, and replacement while preserving case.

UI improvements, including a reworked running kernels section, an “Add a new cell” button at the bottom of a notebook, a dialog to display keyboard shortcuts as in the Classic Notebook (use Ctrl + Shift + H), and displaying the first line of collapsed cell inputs and outputs.

Accessibility improvements, including improved focus and keyboard navigation in the file browser, more ARIA roles and labels for UI elements, and the main menu collapsing to a hamburger menu if there is not enough space to display all items.

Development tool updates to TypeScript v5, Yarn v3, React v18, and Lumino v2. We recommend using Node.js v18 or newer, to ensure that you’re using a version that will continue to receive updates through at least the end of 2023.

Bug fixes. More than 100 bugs have been addressed and resolved, enhancing JupyterLab’s stability and performance. You can find a full list of bug fixes on GitHub.

In addition, a few features in JupyterLab 4 have also been backported to JupyterLab 3.6, but if you’re upgrading from 3.5 or earlier, they will also be new to you:

The dual-mode settings editor now offers a JSON editor and a new, user-friendly interactive mode, built with React JSON Schema. This intuitive interface makes customization accessible to users of all skill levels.

The cell toolbar, a graphical interface for quick cell manipulation (copy, move, insert, delete), provides an alternative to hotkeys or dropdown menu editing. The cell toolbar appears in the current cell as long as there is room for it.

Notifications come from extensions and from JupyterLab itself, for real-time announcements, alerts, and updates. This enhances JupyterLab’s responsiveness and provides a way to stay informed about ongoing processes. Announcements from the JupyterLab team, including new version notifications, can be disabled; see the documentation for instructions.

Thank you to all the users, contributors, extension developers, and community members who helped make this major new release possible. We encourage everyone to try this new version out. If you notice anything unexpected, please file an issue on GitHub or ask us about it on Discourse.

Author’s note: This article is published on behalf of Project Jupyter. I appreciate the contributions of the JupyterLab developers who contributed to it.

Jupyter Blog - JupyterLab

JupyterLab 4.6 and Notebook 7.6 are out!

Enhancements shared by JupyterLab and Notebook

Notebook improvements

File browser: new column, editable breadcrumbs, open in terminal

Debugger: kernel sources filter, floating overlay

Keyboard navigation and accessibility

Keyboard shortcuts

Internationalization

Terminal enhancements

Inline completion enhancements

JupyterLab-specific enhancements

Layout and interface customization

Performance

Notebook-specific enhancements

Scratchpad console

Confirmation dialog when closing and shutting down a notebook

Miscellaneous

For extension authors

As large as minor releases go

Acknowledgements

Further reading

Announcing jupyter-builder: A Standalone Build System for JupyterLab Extensions

Motivation

What jupyter-builder does

Build compatibility without JupyterLab installed

Migrating an existing extension

1. Update the Python build dependencies

2. Update the npm builder dependency

What’s next

Acknowledgements

About the developers

Useful links

A User’s Journey with Plugin Playground: From First Idea to Installable JupyterLab Extension.

Motivation

Journey At a Glance

1.0: Pick Your Starting Path

2.0: Build Extension #1 Manually

2.1: Create the plugin file

2.2: Fill the missing pieces using the right sidebar

2.3: Load it and verify behavior

Expected result:

3.0: Build with AI

3.1: Give AI a precise request

What this block does:

3.2: Use AI + deterministic inserts together

4.0: Iterate Faster Before Handoff

5.0: Share for Review

6.0: Export as Wheel and Validate in Binder

6.1: Export .whl

6.2: Install in Binder

What this block does:

7.0: Export as Zip and Create a GitHub Repository

7.1: Export .zip

7.2: Bootstrap repository

What this block does:

What’s Next

Acknowledgements

About the Developers

Further reading

700 JupyterLab 4 Extensions!

What Are JupyterLab Extensions?

The Ecosystem at 700

How We Got Here

Where the Extensions Are

JupyterLab’s AI Layer Starts Taking Shape

Reproducibility Gets a Toolchain

Science

Accessibility

27 Extensions, One Platform

Want to Build Your Own?

How We Track This

What’s Next

About the author

Instantly view Parquet files in JupyterLab with Arbalister

Arrow over the wire

Looking further

An extension point

About the Author

JupyterLab 4.5 and Notebook 7.5 are available!

What `jupyter-builder` does

6.1: Export `.whl`

7.1: Export `.zip`

Support for collaboration without `RTC:` drive