Jupyter Blog - extensions

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.

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.

Packaging for Jupyter in 2022

2022-09-06T15:15:00+00:00

Packaging has been difficult and changing over time in the Python ecosystem, and packaging extensions for Jupyter has been especially troublesome. Jupyter extensions typically have a build step to handle JavaScript assets, and provide Jupyter configuration and data using the data_files capability in Setuptools. If you’ve ever developed your own Jupyter extension before, you understand the pain all too well.

We’ve tried to help over the years. We created the Jupyter Packaging library, with helper functions and Setuptools builder classes. We have also created cookiecutter repositories for JupyterLab, Widget, and Server extensions. Additionally, there have been a number of libraries and Python Enhancement Proposals produced by the Python Packaging Authority, aiming to standardize and improve the Python Packaging ecosystem. Even with all these improvements, packaging Jupyter libraries remained a challenge.

Then we discovered the Hatch project.

“Hatch is a modern, extensible Python project manager.”

Hatch is a standards-based Python packaging backend that is flexible and extensible. Hatch came with many of the things we needed. It provides a supported replacement for Setuptool’s (deprecated) data_files called shared-data. We could easily extend Hatch to handle the JavaScript build step required for most of our applications and extensions with a new plugin called Hatch Jupyter Builder that is tailored for Jupyter extensions. The best news? No more complicated setup.py files in your package. Just a single, standards-driven pyproject.toml in your root directory describing all of your package details.

We believe this is a major improvement for Jupyter developers and extension authors.

For Jupyter extension authors that previously used one of our cookiecutter templates or Jupyter Packaging directly, we offer a migration script and guides to convert the Setuptools and Jupyter Packaging configuration to use Hatch and Hatch Jupyter Builder. We also provide a script that will compare the files in an sdist or wheel before and after migration to make sure you do not accidentally add or subtract files.

We have already been migrating many of the core Jupyter and IPython libraries to use the Hatch build backend, using Hatch Jupyter Builder where appropriate. We have upgraded several of our cookiecutter templates to use Hatch as well. The transition has been quite smooth!

We highly encourage you to try out Hatch and Hatch Jupyter Builder for existing or new Python libraries.

About the authors

Steven Silvester is a Senior Python Engineer at MongoDB working on the Database Experience Team. He is a Jupyter Steering Council Member and contributes to the maintenance of many of the Jupyter projects.

Zach Sailer is a Senior Software Engineer at Apple, where he is the Jupyter Open Source Champion. He is a Jupyter Distinguished Contributor and leader of the Jupyter Server subproject.

Visual programming in JupyterLab with Blockly

2022-07-29T13:12:00+00:00

Block-based programming has become ubiquitous in school curricula for early computer science education. It is an excellent means to teach basic programming concepts without having to deal with the specific syntax of a text-based programming language.

When moving from block-based programming to a more classical language like Python, students often have to switch to a completely new environment. In order to provide a smooth ramp of complexity for learners, we designed a JupyterLab extension for Blockly so that Jupyter can be used from the very first steps of their learning journey. We also used Blockly’s code generation feature to create a more integrated experience with Jupyter.

But what exactly is Blockly?

The JupyterLab-Blockly extension, running a simple loop, and the corresponding Python code in a cell.

Blockly is an open source library designed by Google to make coding easier and more accessible through block-based visual programming. It uses interlocking graphical blocks to represent coding concepts, while giving the user full creative freedom, it removes all language specific syntax requirements.

Getting started: installing the Blockly extension

To install the extension, you just need to execute the following command:

mamba install -c conda-forge jupyterlab-blockly

Once installed, you can easily open a Blockly editor directly from the launcher, and start experimenting!

Features

The UI is made primarily of the toolbox located on the left side and the canvas where you can drag and drop the blocks you want to use in your code. When you are ready, just click the run button and see how the syntactically correct converted code appears on the bottom part of your screen in the programming language of your choice along with the output!

Short demo for the JupyterLab-Blockly extension

The extension is also prepared to adapt to all your needs. The workspace is ready to generate the blocks using your selected JupyterLab kernel and modify its colors based on your individual theme, whether it’s dark, light or personalized.

JupyterLab-Blockly integrates smoothly with the rest of the Jupyter stack: by using Jupyter kernels to execute the generated code, by reusing the JupyterLab code cell component to display the generated code, etc.

In doing so, JupyterLab-Blockly remains consistent with the rest of the UI (consistent syntax highlighting, theming, and life cycle of Jupyter kernels).

Robotics education

On top of JupyterLab-Blockly, we also built another extension dedicated to operating robots with the help of visual programming — more specifically, we created a toolbox which includes the blocks necessary to control the Niryo One robot. Using ROS can be a time consuming task, but the pre-built visual blocks make it easier to experiment and faster to produce a prototype for any project you have in mind.

To install this extension you need to execute the following commands:

mamba install -c conda-forge jupyterlab-niryo-one

Then, all you need to do is switch from the ‘default’ toolbox to the ‘niryo’ one, and you will immediately gain access to forty-two new blocks, so if you have access to one of these robots, give it a try!

Short demo for the JupyterLab-NiryoOne extension

Both extensions can be found on GitHub. The JupyterLab-Blockly extension is ready to be used as a base for other projects; you can register new blocks, toolboxes and generators. Taking the JupyterLab-Niryo-One extension as an example, feel free to experiment on your own!

Controlling the Niryo-one robot with the JupyterLab-blockly extension.

You can also try out the JupyterLab-Blockly extension now, directly from your browser, using JupyterLite! Just click on the link below.

About the authors

Denisa Checiu is a Robotics working student at QuantStack. She is also currently pursuing her bachelor’s degree, majoring in Robotics and Intelligent Systems and minoring in Computer Science.

Carlos Herrero is a scientific software developer at QuantStack passionate about AI and its applications to robotics. His current work focuses on the JupyterLab stack and expanding the Jupyter ecosystem by developing new extensions to integrate ROS in JupyterLab and also contributing to Voilà.

Jupyter Blog - extensions

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

A theme editor for JupyterLab

Packaging for Jupyter in 2022

About the authors

Visual programming in JupyterLab with Blockly

But what exactly is Blockly?

Getting started: installing the Blockly extension

Features

Robotics education

About the authors

What `jupyter-builder` does

6.1: Export `.whl`

7.1: Export `.zip`