Jupyter Blog - Martin Renou

JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more

2026-08-24T16:09:00+00:00

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

Earlier this year, we introduced STAC browsing and Story Maps in JupyterGIS, making it easier to discover geospatial datasets and communicate results without leaving Jupyter.

JupyterGIS 0.16 continues in the same direction. This release adds support for new geospatial formats, tighter integration with the scientific Python ecosystem, a redesigned Story Map editor, and a more expressive way to style geographic data.

Story Maps are getting a new look!

Story Maps in JupyterGIS let you build a scrollable presentation around your map. A Story Map is made up of a sequence of segments that can combine Markdown content with map views, so you can guide the reader through a geographic story as they scroll.

Each segment can define its own map state, including the current map location, visible layers, and layer styling. This means that the map can change as the reader moves through the story: layers can appear or disappear, the view can move to a new location, and symbology can change to highlight different aspects of the data.

Story Maps have received a significant update in this release.

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

The Story-map associated to this release annoucement. It contains Text, images, and map views with associated layer states.

A better Story Maps editing experience

We’ve also made substantial improvements to the Story Map editing experience.

The editor has been redesigned around Jupyter’s real-time collaboration infrastructure, allowing multiple people to edit the same Story Map simultaneously. Changes appear immediately for everyone, making it much easier to prepare presentations, reports, or educational material as a team.

Collaboratively edit the Story Map markdown.

The editor now gives you a much better sense of what the final story will look like while you are working on it. Markdown sections can be previewed directly in the editor, and a new Story Map preview makes it possible to see the complete presentation without leaving the editing workflow. This makes it easier to write, arrange, and refine a story while keeping an eye on the final result. We’ve also introduced a new layout that is better suited for long-form content. In addition to guided geographic narratives, Story Maps can now be used to create richer articles combining text, maps, images, and other interactive content.

New Story Map editor: Set story segment viewport, preview markdown, set layers properties for the story segment.

OpenEO layers

More and more geospatial workflows rely on remote processing instead of downloading datasets locally. openEO provides a common API to describe these processing pipelines as process graphs that are executed by a backend.

JupyterGIS can now display openEO process graphs directly as map layers. Instead of exporting intermediate results before visualizing them, you can connect an openEO backend and inspect the output of your processing pipeline directly in the map.

The visualization is tile-based and lazy: JupyterGIS only requests the data needed for the current map view and zoom level. This makes it possible to explore large remote sensing workflows interactively, without materializing the full result locally.

JupyterGIS can make use of any openEO server that supports tiling, such as titiler-openeo

import openeo
from jupytergis import GISDocument
from openeo.processes import process

connection = openeo.connect(SERVER_URL)
connection.authenticate_basic(username=BASIC_AUTH, password=BASIC_AUTH)

cube = connection.load_collection(
    "sentinel-2-global-mosaics",
    bands=["B03", "B08"],
    temporal_extent=["2022-04-15", "2022-12-31"],
)

cube = cube.reduce_dimension(
    dimension="t",
    reducer="first",
)

cube = cube / 10000.0

# NDWI = (GREEN - NIR) / (GREEN + NIR)
ndwi = cube.ndvi(nir="0", red="1")

ndwi_vis = (ndwi + 1) / 2

ndwi_png = ndwi_vis.linear_scale_range(
    input_min=0,
    input_max=1,
    output_min=0,
    output_max=255,
)

result = ndwi_png.save_result(format="PNG")

doc = GISDocument(latitude=40.75, longitude=-73.95, zoom=12)
await doc.ready()
doc.add_openeo_tile_layer(result)
doc

Define a process graph to compute a NDWI, using the Python API of OpenEO and JupyterGIS. It is then lazily evaluated on a per-tile basis while the user pans/zooms on the map.

In addition to defining openEO process graphs from the scripting Python API, JupyterGIS provides an advanced openEO process graph editor, allowing you to:

connect to an openEO tile server
define the graph graphically, with boxes and arrows
load data collections and define processes with a drag-and-drop UI
directly edit the JSON content

Editing an openEO process graph from the JupyterGIS front-end

Another interesting aspect of openEO is that process graphs have a well-defined, declarative JSON representation. Because of this structured format, they are a natural target for LLM-assisted workflows. Users can describe the analysis they want in natural language, have an LLM generate or refine the corresponding process graph (e.g. using jupyterlite-ai), and immediately visualize the result in JupyterGIS. Combined with the lazy, tile-based rendering, this makes it possible to quickly iterate on processing pipelines without waiting for complete datasets to be exported or downloaded.

Lazy visualization of Xarray datasets with jupyter-tiler

JupyterGIS now integrates with the new jupyter-tiler package, making it straightforward to visualize Xarray datasets from Python.

Datasets can come from anywhere: they may already exist in your notebook, or they can be loaded on demand from a STAC catalog using stackstac. Once you have an Xarray object, JupyterGIS can display it in the map without requiring an export to another format.

Rendering happens lazily, generating only the tiles needed for the current view. This makes it possible to explore datasets that are much larger than memory while keeping navigation responsive.

The result is a smoother workflow from data loading, to analysis, to visualization, all within the same notebook.

await doc.add_data_array_layer(
    name="NDSI Layer",
    data_array=ndsi,
    colormap_name="viridis",
    colormap_range=(-1, 1),
)

Visualizing an Xarray dataset in JupyterGIS.

This feature requires the optional dependency jupyter-tiler to be installed.

pip install jupyter-tiler

A more expressive symbology model

Styling geographic data often requires combining multiple visual properties to communicate patterns effectively.

JupyterGIS 0.16 introduces a new symbology model inspired by the Grammar of Graphics. Instead of relying on a fixed set of styling options, visual properties such as color, size, and opacity can be defined in a more flexible and composable way.

This makes it easier to build everything from simple thematic maps to more advanced visualizations while keeping styling definitions consistent and reproducible.

A symbology example: apply a Viridis color map to the circle colors, a linear scale to the radius of circles, and a fixed stroke color.

GeoZarr and GeoPackage support

This release also expands the range of formats that JupyterGIS can open directly.

Support for GeoZarr makes it possible to work with cloud-native multidimensional geospatial datasets, while GeoPackage support improves interoperability with existing GIS software and common data exchange workflows.

New Collaborative Editing Capabilities

JupyterGIS 0.16 also brings collaborative editing to vector layers. When working on a shared JupyterGIS document, multiple users can now edit the same vector data at the same time.

Features can be created, moved, and edited collaboratively, with changes synchronized in real time between users. This makes it possible to work together on tasks such as digitizing features, annotating a map, or refining a dataset without having to exchange files or manually merge changes.

Combined with the collaborative Story Map editor, this makes collaboration a more integral part of JupyterGIS: users can work together on the data itself, and then use the same shared document to explore and communicate their results.

A new R API

JupyterGIS 0.16 also introduces an R client, bringing JupyterGIS to R users through the new r-jupytergis package. The R client provides bindings for interacting with JupyterGIS widgets from an R notebook, using the same JavaScript front-end as the Python client.

The main interface is the GISDocument widget, which can be used to create and manipulate JupyterGIS documents directly from R. This makes it possible to build geospatial workflows in R while using the same interactive map interface available to Python users.

The R client also uses the same underlying collaborative infrastructure as the Python client, including the Yrs CRDT library. This means that R users can participate in the same collaborative JupyterGIS workflows rather than working in a separate environment.

doc <- GISDocument$new("france_hiking.jGIS")
layer <- doc$add_raster_layer(
    url = "https://mt1.google.com/vt/lyrs=y&x={x}&y={y}&z={z}",
    name = "Google Satellite",
    attribution = "Google",
    opacity = 0.6
)

Bug fixes and performance improvements

As usual, this release also includes many smaller improvements throughout the project.

We’ve fixed a number of bugs, improved performance in several parts of the application, and continued polishing both the user interface and the Python API.

JupyterGIS continues to evolve as a collaborative GIS environment that fits naturally within the Jupyter ecosystem. Whether your workflow starts from a notebook, a STAC catalog, an openEO backend, or a local dataset, the goal remains the same: make it easier to move between analysis, visualization, and communication without switching tools.

Acknowledgements

This work on JupyterGIS by QuantStack was funded by the European Space Agency (ESA) for the Story-maps development, the R API, openEO layers support and the collaborative labelling. Additionally, QuantStack was funded by the French National Centre for Space Studies (CNES) for the lazy visualization of xarray datasets.

Contributors to this release

By order of number of contributions:

Arjun Verma is a Developer at QuantStack. He worked on the server-side geoprocessing infrastructure and on the openEO editor in the JupyterGIS front-end.

Martin Renou is a Technical Director at QuantStack and a maintainer of JupyterGIS. For this release, Martin coordinated and guided much of the development, and worked on the integration of openEO layers.

Gregory Mooney is a Developer at QuantStack and a long-time contributor to JupyterGIS. He led much of the work on the new Story Map editor and its collaborative editing capabilities.

Matthias Meschede is Chief Operating Officer at QuantStack. He introduced the new Grammar of Graphics-inspired symbology model, bringing a more expressive and composable approach to styling geographic data.

Matt Fisher is the Community Manager of GeoJupyter. He contributed to many of the discussions around the release and helped shape several of the design decisions across the project.

Nakul Verma is an open-source contributor to JupyterGIS. He contributed numerous bug fixes and improvements throughout the release, and introduced support for Vega expressions in the new symbology system.

Antoine Prouvost is a Developer at QuantStack. He led the initial work on the R API for JupyterGIS, building its first skeleton and establishing the foundations for the r-jupytergis package.

Sandrine Pataut is a Developer at QuantStack. She worked on bringing many of JupyterGIS’s features to the R API, helping make the new client more complete and useful for R users.

We are grateful to everyone who contributed code, reviews, ideas, discussions, and feedback to this release. JupyterGIS continues to benefit from an increasingly diverse community of contributors, and we look forward to seeing what comes next!

Collaborative editing for GIS workflows with Jupyter and QGIS

2025-02-26T18:50:00+00:00

The QGIS open-source project is a cornerstone in the geosciences ecosystem, providing robust tools for spatial data analysis and visualisation. While QGIS excels in empowering researchers and engineers, the evolving landscape of geospatial research demands enhanced collaboration and accessibility, prompting a shift towards web-based technologies.

Collaboration in Jupyter

Collaboration has long been a key requirement for data science and scientific computing workflows, but Jupyter Notebooks historically lacked built-in real-time collaboration features.

To bridge this gap, the jupyter-collaboration project has focused on integrating multi-user editing capabilities directly into JupyterLab and Jupyter Notebook. This effort builds on foundational work in conflict-free replicated data types (CRDTs), leveraging technologies like Yjs, and required integration into the Notebook document model and WebSocket-based architecture.

Making Notebook code suggestions in collaboration mode with https://github.com/jupyterlab-contrib/jupyter-suggestions

This approach did not only enable collaborative editing of notebooks, but also opened the door for collaboration on other editing UIs. This was done e.g. in JupyterCAD, a 3D parametric modeler that allows multiple users to collaboratively design and manipulate CAD models within JupyterLab.

Read more about JupyterCAD here Announcing JupyterCAD 3.0

Collaboration in JupyterCAD

Introducing JupyterGIS

Today, we are excited to announce JupyterGIS, a web-based, collaborative, and extensible interface for GIS, leveraging the JupyterLab application framework and integrating seamlessly with the Jupyter notebook interface.

JupyterGIS provides the following key features:

a JupyterLab extension for collaborative editing of geospatial data files: with COG, Shapefile, GeoJSON data source support,
support for importing, exporting and collaborating with QGIS files,
advanced analysis and editing features with an identify tool and a symbology panel approaching what QGIS provides,
easily share and deploy GIS projects using JupyterLite.

Note: JupyterGIS is not an official Jupyter subproject.

GIS features

Raster and vector layers

JupyterGIS allows you to create multiple types of raster and vector layers, including local or remote GeoTIFFs, GeoJSON, shapefiles, and tile services.

You can select from a set of pre-defined tile services in our gallery, or you can provide your own source.

Identify tool and filtering

Akin to QGIS, we provide an identify tool and filtering capabilities, helping you to inspect your datasource.

Symbology

The symbology of a layer refers to its visual representation on the map, helping you to analyze your data comfortably. JupyterGIS provides a similar feature for its raster and vector layers.

Spatio-temporal data

You can easily animate and analyze your spatio-temporal data.

Python API

Even though you can do most operations from the UI, JupyterGIS also provides a Python API enabling scripting capabilities, which can be used to process data and operate on JupyterGIS documents programmatically from a Jupyter notebook.

Collaborative features

Building upon our previous work to enable collaborative editing in JupyterCAD, we developed a shared document model to support multi-user workflows in JupyterGIS.

Everything is shared between collaborators, from layers data to symbology and filtering rules.

We also provide some collaboration features like the ability to see other collaborators’ cursors, follow collaborators’ viewports, add geolocated Google Docs-like comment conversations, and see what layer features collaborators are identifying.

Try it!

You can directly try JupyterGIS in your browser, without installing anything, thanks to JupyterLite:

https://jupytergis.readthedocs.io/en/latest/lite/lab/index.html

Documentation

Check out the Python API reference and tutorials on how to get started in our documentation:

https://jupytergis.readthedocs.io

What’s next?

We are excited to welcome new contributors and see the JupyterGIS community grow. Here are some exciting developments on our radar for the future:

Support for more data source types.
Processing tools,
Support for suggestions by collaborators, similar to the inline suggestions feature of JupyterCAD,
An improved and more featureful Python API,
A better coverage of QGIS features.

How can you support our work?

Your support is important, if you would like to help us build more exciting tools around JupyterGIS, do not hesitate to contact us on the public geojupyter Zulip channel!

Additionally, you can join us for the bi-weekly GeoJupyter hackathon on Wednesday https://geojupyter.org/calendar.html

Acknowledgments

This work on JupyterGIS by QuantStack and Simula Research Lab (Simula) was funded by the European Space Agency (ESA) for our proposal “Real-time collaboration and collaborative editing for GIS workflows with Jupyter and QGIS”.

We are also grateful to The Eric and Wendy Schmidt Center for Data Science & Environment (DSE) at UC Berkeley for funding the work of Matt Fisher on the project.

Finally, this wouldn’t have been possible without the foundational work on JupyterCAD initiated by Duc Trung Le.

About the JupyterGIS contributors

Meriem Ben Ismail is a Scientific Software Developer at QuantStack. She 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.

Nicolas Brichet is a Scientific Software Developer at QuantStack. He holds a master’s degree in robotics from the University of Montpellier. Prior to joining Quantstack, Nicolas worked for almost fourteen years in French research institutes (INRAE and CNRS), as software developer for scientific research. He also worked on different parts of the data lifecycle, such as data acquisition, analysis, and storage.

David Brochart is a Technical Director at QuantStack. David used to work in the semiconductor industry as a digital circuit designer, mostly using FPGAs. He studied telecommunications at the French “Telecom Bretagne” engineering school, with major in digital circuit design. David also worked as a researcher in hydrology at Irstea, a French scientific research institute, where he heavily used the Python scientific stack.

Matt Fisher is a Research Software Engineer and Community Manager at Schmidt Center for Data Science & Environment. Matt is passionate about open science, community-owned software, teaching and learning, accessibility, and inclusion. It is his treasured privilege to support researchers and educators in their missions by working on projects like QGreenland and JupyterGIS!

Anne Fouilloux, a Senior Research Engineer, specializes in Open Science, FAIR data, and Big Data analytics. With a PhD in Atmospheric Physics, she has contributed to Pangeo and EOSC (European Open Science Cloud), focusing on data management, Earth system modeling, and scalable computing. A strong advocate for Open Science, she advances data accessibility and interoperability to drive scientific innovation.

Greg Mooney is a Scientific Computing Developer at QuantStack. He received a Bachelors degree in Software Engineering from Arizona State University (ASU). Before joining QuantStack, he worked as an Aegis Computer Network Technician, working on the network infrastructure connecting various sensor systems onboard naval vessels.

Martin Renou is a Technical Director at QuantStack and a maintainer of Project Jupyter. Among other projects Martin is a core team member of the ipywidgets project and maintains many Jupyter widget packages such as ipyleaflet, ipydatagrid, ipygany, ipycanvas, and bqplot. He is a co-creator of the Voilà dashboarding system, and the xeus-python kernel.

Arjun Verma is a Scientific Software Development Intern at QuantStack. He is also a final year undergraduate student at Cluster Innovation Centre, University of Delhi. He loves 3D & GIS and also contributes to JupyterCAD and is one of the maintainers of PyBaMM where he has also been GSoC contributor and mentor.

Announcing JupyterCAD 3.0

2025-02-17T09:38:00+00:00

We are thrilled to introduce JupyterCAD 3.0, the newest version of the collaborative CAD modeler designed for JupyterLab.

JupyterCAD is an unofficial JupyterLab extension for 3D geometry modeling with collaborative editing support. It is designed to allow multiple people to work on the same file at the same time, and to facilitate discussion and collaboration around the 3D shapes being created.

JupyterCAD 3.0 represents a significant leap forward in usability and user experience compared to the previous release.

What’s new in JupyterCAD 3.0?

Color customization

JupyterCAD 3.0 allows you to customize object colors directly within the application, while we were limited to gray models in earlier versions. Adjust colors easily to suit your design needs or preferences.

Embedded Python console

The new embedded Python console offers advanced users direct access to JupyterCAD’s Python API, enabling on-the-fly scripting and automation for power users.

UX improvements

The new AxesHelper provides a clear visual reference for coordinate axes, making it easier to navigate and align models in 3D space.

We have also added copy-paste functionality using Ctrl+C and Ctrl+V shortcuts, making it faster and easier to duplicate objects within your models.

An improved toolbar now includes options to toggle wireframe, toggle transform controls, toggle clip plane and a toggleable console, giving users quick access to essential tools.

JupyterCAD 3.0 also introduces smooth camera tracking, where selecting an object from the object tree triggers a smooth transition of the camera to focus on the selected object, enhancing navigation and model exploration.

Mouse-based 3D controls

Move or rotate your 3D models effortlessly with mouse-based controls that bring fluidity and precision to model editing and interaction.

Suggestions support

With JupyterCAD 3.0, collaboration becomes even more seamless with suggestions. Collaborators can propose changes to a model, which can be reviewed and applied collaboratively, fostering a dynamic and efficient workflow.

Try it!

Screenshot of JupyterCAD GitHub repository, with a link to try JupyterCAD (circled in red) with JupyterLite. This is simply deployed as a static website on “GitHub Pages”.

Explore JupyterCAD 3.0 in action with our JupyterLite deployment — no installation required. Visit us at jupytercad.github.io/JupyterCAD and start modeling directly in your browser.

Installing JupyterCAD

You can easily install JupyterCAD with pip or mamba:

pip install jupytercad

or:

mamba install -c conda-forge jupytercad

Additionally, you can install FreeCAD along with the JupyterCAD-FreeCAD plugin to enable support for FCstd files:

mamba install -c conda-forge freecad jupytercad-freecad

What’s next?

JupyterCAD is evolving rapidly, with some exciting updates just around the corner and others in active development:

Upcoming Features

Enhanced User Experience:
- Smoother exploded view
- Support for renaming objects directly from object tree
- Incremental rotation controls for precise adjustments
- Enhanced 3D view settings for better customization.
Nested & Refined Side Panel: Navigate and organize objects more easily with a refined and nested side panel experience.
Support for more File Formats: Broaden compatibility with support for more file formats.

Features in Development

New CAD Operations: New tools for operations like linear and radial patterns to expand modeling capabilities.
Support for measuring distances: Tools to measure distances and dimensions directly in the viewport.
Improved 2D Sketcher: Enhanced features to make 2D sketching more intuitive and robust.

Acknowledgements

The development of the JupyterCAD open-source project by QuantStack was funded by a grant from DGAC in the framework of the French “Plan de Relance” (refinanced by Next generation EU) as part of a collaboration between Safran Aircraft Engines, INRIA, and Akkodis.

We also extend our gratitude to the external contributors whose efforts and feedback have been instrumental in shaping this release. Your support and collaboration drive the ongoing success of JupyterCAD.

This work was built upon the strong foundation laid by open-source software projects such as Three.js, OpenCascade, OpenCascade.js, FreeCAD, JupyterLab and JupyterLite.

About the authors

JupyterCAD is an open-source project resulting from contributors’ collective efforts. Below, we highlight the primary contributors for this release:

Le Duc Trung is a Scientific Software Developer at QuantStack. He works on several projects within the Jupyter ecosystem, from the main projects like JupyterLab, Voilà, and ipywidgets to various JupyterLab extensions and widgets.

Arjun Verma is a Scientific Software Development Intern at QuantStack. He is also a final year undergraduate student at Cluster Innovation Centre, University of Delhi. He loves 3D & GIS and also contributes to JupyterGIS and is one of the maintainers of PyBaMM where he has also been GSoC contributor and mentor.

And Voici!

2023-12-06T15:21:00+00:00

Voici (meaning “here is” in French) is a novel project reshaping Jupyter-based interactive dashboards by combining Voilà and JupyterLite features. It facilitates the creation of dynamic, in-browser environments for data visualization and exploration.

Built upon the foundations of Voilà, Voici inherits the ability to convert any Jupyter notebook into a standalone user-friendly dashboard. While the simplicity and extensibility of Voilà are kept intact, Voici adopts the in-browser execution model of JupyterLite, replacing the client-server approach.

Dashboards generated by Voici are simply a collection of static files. Deploying and scaling such dashboards is straightforward since there is no need to allocate computational resources in the backend.

Voici dashboards are extraordinarily scalable compared to their “Voilà” counterparts, since they don’t require a container per user session.

Voilà and Voici, as their name suggests, share a lot of commonalities like the CLI, the configuration options, and the templating system. The difference in their execution model results in a distinction: Voilà can hide the source code from the browser, displaying only the rendered dashboard, whereas Voici exposes the entire notebook content to the front end.

From a notebook to a Voici dashboard

Installation and first-time use

You can install Voici using pip:

pip install voici

Or using conda/mamba:

mamba install voici -c conda-forge

Upon installation, the Voici command-line utility becomes available and can be used as a drop-in replacement for the voila command. For example, you can generate static dashboards from a notebook or a directory of notebooks like this:

# Build a single dashboard
voici my-notebook.ipynb

# Build a directory of notebooks
voici notebooks/

# Build a dashboard with a dark theme and voila-gridstack template
voici my-notebook.ipynb --template gridstack --theme dark

Once the dashboards are built in the _output directory, you can simply serve the static web page with your favorite web server. For example, using CPython’s simple HTTP server:

python -m http.server -d _output

A Voici dashboard using the dark theme

For the configurations of the themes, templates, or the tree page, you can refer to the Voilà documentation for available options. The Voici-specific configurations can be found in the Voici documentation.

Deploy Voici dashboard

Besides the static site hosting services, it is also possible to deploy Voici dashboards to GitHub Pages directly from your repository or to embed them into Sphinx documentation.

Publishing Voici dashboards on GitHub Pages

Creating your deployment on GitHub Pages is straightforward with the help of a template repository available on GitHub. You can follow the instructions from the following video:

The dashboard will be built by the CI action and published on the corresponding GitHub page of your repository.

Embedding Voici dashboards in Sphinx documentation

jupyterlite-sphinx is a Python package that allows embedding Jupyterlite in Sphinx documentation using simple directives. It is used in the documentation of major projects like scikit-image or ipywidgets.

In addition to JupyterLite applications, this package also supports embedding Voici dashboards with the voici directive:

.. voici:: my_notebook.ipynb
  :height: 600px
  :prompt: Try Voici!
  :prompt_color: #dc3545

With this directive, the Voici dashboard will be generated automatically with the Sphinx documentation, and the dashboard will be loaded as per user request.

A Voici dashboard embedded in Sphinx documentation

Voici gallery

The Voici gallery is a collection of dashboards built with Voici, it aims to provide a source of inspiration for crafting complex dashboards entirely based on the Jupyter ecosystem.

Voici Gallery home page

If you’ve created an interesting dashboard and would like to share it with a wider audience, don’t hesitate to submit a pull request here to have it included in the list of examples!

Future development

Voici is rapidly evolving, with many improvements already in the works such as:

Better integration with JupyterLab and JupyterLite to preview and generate Voici dashboards from their user interface.
Provide more user-friendly tools to easily deploy Voici dashboards to other platforms like GitLab and HuggingFace,…

User feedback from the community also plays a big role in the project roadmap. Explore Voici and share your thoughts with us using the project’s GitHub issues!

About the authors

Martin Renou is a Technical Director at QuantStack and a maintainer of Project Jupyter. Among other projects Martin is a core team member of the ipywidgets project and maintains many Jupyter widget packages such as ipyleaflet, ipydatagrid, ipygany, ipycanvas, and bqplot. He is a co-creator of the Voilà dashboarding system, and the xeus-python kernel.

Collaborative CAD in JupyterLab

2023-06-02T15:15:00+00:00

We are thrilled to introduce JupyterCAD, a tool that integrates Computer-Aided Design (CAD) capabilities into JupyterLab. With its JupyterLab extension, dedicated JupyterCAD application, and Python API for CAD operations, JupyterCAD allows users to effortlessly create, edit and share 3D designs without leaving the Jupyter ecosystem.

This blog post provides an overview of JupyterCAD’s features and highlights its collaborative editing capabilities which enable teamwork in the realm of CAD.

Everything that is shown below can be tested by installing JupyterCAD from PyPI:

# From PyPI
pip install jupytercad

One extension, three interfaces

Built using the latest JupyterLab 4 release, JupyterCAD combines CAD functionalities with the enhanced performance and accessibility improvements introduced in JupyterLab 4. The flexibility of JupyterLab allows us to create the extension once but deploy it in multiple ways to target three groups of audiences: users who prefer working in the JupyterLab environment, users who favor dedicated applications, and those advanced users who do everything programmatically.

JupyterLab Extension

Experience CAD features directly within JupyterLab with the JupyterCAD extension. Open and edit FreeCAD files, perform CAD operations, including creating 3D primitives, applying boolean operators, and exploding the view. JupyterCAD’s extension integrates seamlessly into JupyterLab, providing an intuitive environment for CAD enthusiasts and data scientists alike.

JupyterCAD extension inside JupyterLab

JupyterCAD Application

For a streamlined CAD experience, JupyterCAD offers a dedicated application that eliminates distractions and emphasizes CAD features.

The standalone JupyterCAD Application.

Starting the dedicated JupyterCAD application is as simple as starting JupyterLab or Jupyter Notebook:

jupyter cad

This dedicated application has been built in a similar way to the coming Jupyter Notebook 7. It’s a JupyterLab “remix” built from the ground up using JupyterLab core components and custom extensions. Much like JupyterLab, it offers theming and localization support, and more planned features on the horizon.

Python API for CAD Operations

Advanced users can unlock the full potential of CAD operations with JupyterCAD’s Python API. JupyterCAD allows users to programmatically visualize, create, and manipulate the shapes from a Jupyter Notebook. For example, one can open a FreeCAD file and start modifying it from the notebook with:

from jupytercad import CadDocument
doc = CadDocument('example.FCStd')
# Create a cone, a sphere then cut the cone with the sphere.
doc.add_cone().add_sphere(radius=0.8).cut()
display(doc)

Adding object to FreeCAD file from Jupyter Notebook.

JupyterCAD API also integrates nicely with the OpenCascade Python API, providing expanded capabilities for working with shapes.

from jupytercad import CadDocument
...
# Create a prism shape with OpenCascade
prism = BRepPrimAPI_MakePrism(profile, vec).Shape()
doc = CadDocument()
doc.add_occ_shape(prism)
display(doc)

Visualize OpenCascade shape object with JupyterCAD.

Unlocking teamwork with real-time collaboration

Collaborative Editing

One of the standout features of JupyterCAD is its shared editing functionality, which seamlessly connects users across different interfaces within the JupyterCAD ecosystem. Whether collaborators are using the dedicated JupyterCAD application, the JupyterLab extension, or working with the Python API in a Notebook, any changes made to a shared document are instantly reflected for all users.

Real-time collaboration allows individuals working in the Python API to make modifications to the CAD document, while simultaneously providing a synchronized view for collaborators using the JupyterLab extension or the JupyterCAD application. This ensures that all participants have access to the most up-to-date version of the design, fostering efficient communication and eliminating the need for manual synchronization or file exchange.

Real-time collaborative editing in JupyterCAD.

Follow Mode

With JupyterCAD’s follow-mode feature, collaboration becomes even more fluid. You can follow another user’s camera movements and view adjustments in real-time. This mode allows you to gain insights into the design process, and enhance communication among team members.

Follow Mode in action.

Annotations System

The annotations system in JupyterCAD adds an interactive layer to 3D designs. Now you can add annotations to specific shapes within a CAD file, give context, provide feedback, or write instructions.

Adding annotation at precise positions

What goes on under the hood?

All the above features are made possible thanks to two major open-source components: OpenCascade.js, the WebAssembly build of OpenCascade, and jupyter_collaboration, the real-time collaboration framework of JupyterLab.

In-browser geometric modeling kernel

To execute all geometric operations, JupyterCAD uses a custom build of OpenCascade.js, which is a port of the OpenCascade library to JavaScript and WebAssembly via Emscripten. Running on a separate thread, the CAD Kernel of JupyterCAD allows users to perform complex operations at near-native speed. It also helps to lower the load of the server while serving JupyterCAD to many users.

JupyterLab Real-Time Collaboration framework

In JupyterLab 4, Real-Time Collaboration (RTC) is not only about editing notebooks but it has become a framework for building collaborative applications. Using the components of jupyter_collaboration helps us accelerate the development of the RTC features in JupyterCAD. Collaborative Editing is built upon a shared data model where jupyter_collaboration handles all the transportation and conflict resolution, while Follow Mode makes use of Awareness, a lightweight notification system provided by the library.

Future work

The current state of JupyterCAD illustrates the capabilities of JupyterLab as a foundation to build complex applications, not just for scientific computing but also for more general technical computing applications.

We will continue to improve JupyterCAD on two axes:

Enhancing the 3D viewer with features to help users interact with the objects
Enriching the Python API to improve interoperability with other CAD libraries

We plan on upstreaming some of the features of JupyterCAD, like the annotations system and the Follow Mode, to jupyter_collaboration to enable it in other file contexts in JupyterLab (Notebooks, text files, etc).

User feedback from the community also plays a big role in the project roadmap. Try JupyterCAD and share your feedback with us using the project’s GitHub issues!

About the Authors

Mamba meets JupyterLite

2022-07-14T11:19:00+00:00

JupyterLite is a Jupyter distribution that runs entirely in the web browser without any server components. To achieve this, all language kernels must also run in the browser.

JupyterLite running in the browser as a static website

A significant benefit of this approach is the ease of deployment. With JupyterLite, the only requirement to provide a live computing environment is a collection of static assets. It makes it possible to embed a console or a notebook interface on any static page or blog without having to deal with a server architecture deployment. The scalability of this approach allowed several major projects of our ecosystem (NumPy, SymPy, Pandas, PyMC, and many more) to embed interactive examples on their websites, which are visited by millions of users monthly.

JupyterLite is the easiest and most scalable way to embed an interactive console or notebook on a web page without any server component.

The most prominent JupyterLite kernel is the Pyolite Python kernel, which is based on the Pyodide distribution for WebAssembly. Beyond the CPython interpreter, Pyodide includes many popular scientific computing packages such as NumPy, Pandas, and Matplotlib. Pyodide also provides a foreign function interface (FFI) that allows calling Python from JavaScript and vice versa.

The JupyterLite inline console embedded on the SymPy project website

Pyodide — and beyond

While Pyodide provides many scientific computing packages, its monolithic distribution model does not allow to specify package versions, although versions of pure python packages installed on top can be set. Our goal is to enable the composability of computing environments allowed by package managers and to adopt the conda-forge model for large-scale software distribution crowdsourcing.

Being able to pin down package versions in an environment is a strong requirement for software reproducibility. In fact, a locked WebAssembly environment could be seen as a reproducibility time capsule. As WebAssembly is a recognized web standard, it ought to be runnable for much longer than native binary packages: these are bound to a combination of architecture and platform and will eventually require an emulator.

This is why we developed a mamba-based distribution of WebAssembly packages built with Emscripten.

Emscripten-forge

The choice of the Mamba/Conda package manager was natural. Its main strength is the conda-forge community-maintained distribution, which has become the de facto standard source of packages for scientific computing.

Beyond its solid technological foundations and the multi-platform nature of the conda-forge distribution, its main strength is its social model. It allowed for a crowdsourcing approach of the packaging problem, with a balance of separation of concerns between maintainer teams and across-the-board automation, plus an amazing maintainers community.

We plan on contributing this work to the conda-forge project, so that all recipes live in the same space.

The Mamba/Conda package manager has support for many platforms and architectures such as Linux, OS X (for both x86 and arm64), and Windows. However, the WebAssembly family of platforms is not supported yet.

Adding support for WebAssembly to mamba & conda

To create conda packages for the WebAssembly platform, we relied on the Emscripten toolchain.

We defined a new target platform for conda-build and boa, namely wasm32-unknown-emscripten for which we use the emscripten-32 shorthand name. We then associated the Emscripten compiler, wrapped in a conda package as the C/C++ compiler for this new target.
This already allowed us to build many packages, including simple libraries like bzip2 and zlib, but also more complex packages like Python.
For Python extension modules we used crossenv which can create virtual environments for cross-compiling, and cross-python which integrates crossenv into conda. All the code and recipes for cross-compilation are hosted on the emscripten-forge GitHub repository.
We then used GitHub actions to build packages with Emscripten and upload them to a package server.
Packages are hosted on a deployment of the Quetz open-source server.

With this, you can easily create an environment for the emscripten-32 target:

micromamba create -n my-env --platform=emscripten-32 \
    -c https://repo.mamba.pm/emscripten-forge \
    -c https://repo.mamba.pm/conda-forge \
    python ipython numpy jedi

Note that we not only added emscripten-forge as a channel, but also conda-forge. This means all noarch packages can be used.

Adding new packages to the emscripten-forge channel

Adding new packages is a simple procedure:

fork the repository https://github.com/emscripten-forge/recipes
create a folder for your package in recipes/recipes_emscripten/<my_package>
add a recipe.yaml for your package in recipes/recipes_emscripten/<your_package>
create a pull request containing the recipe. Once the pull request is merged, the package is automatically uploaded to the emscripten-forge channel.

Integration with JupyterLite

Even though this is a general-purpose conda-based distribution for Emscripten packages, we had one particular application in mind for this first iteration: JupyterLite. The existing Pyolite kernel is too tightly coupled with the Pyodide distribution, so we decided to go with xeus-python instead.

The main reason for picking xeus-python (over ipykernel) is that with xeus-based kernels, it is possible to override the communication layer of the kernel (switching e.g. from ZMQ to HTTP/2). In the case of JupyterLite, the implementation simply relies on direct JavaScript function calls.

You can check out our earlier blog post for more details on the JupyterLite xeus-based kernels.

Providing a complete Python development experience

Some remaining intrinsic limitations to the WebAssembly platform need to be worked around to provide a complete experience to end-users. For example, sockets cannot be created in WebAssembly, preventing the use of the default asyncio event loop implementation. Luckily, the Pyodide authors developed a custom asyncio event-loop called WebLoop: it wraps the browser event loop using the Python — JavaScript foreign function interface (FFI) provided with Pyodide.

Pyjs

Since it is non-trivial to extract Pyodide’s FFI and use it for other projects, we created a modern Python - JavaScript FFI from scratch. This was done with the following tricks:

Pybind11 is used to call Python from C++ and vice versa,
Embind is used to call JavaScript from C++ and vice versa.

When we use Pybind11 and Embind together we can call Python from JavaScript and vice versa, with C++ as a man in the middle. This not only allows us to write a simple FFI from scratch with relatively little code but also avoids calling any low-level CPython APIs and enables using high-level constructs — like pybind11::object and emscripten::val— instead.
The code is available in the pyjs repository. The API is very similar to Pyodide’s so that it can be used as a drop-in replacement in code, like Pyodide’s WebLoop implementation.

Deployment

The xeus-python-kernel allows conda packages to be pre-installed in the Python runtime. This can be done by passing the XeusPythonEnv.packages CLI option to jupyter lite build. The following command will install NumPy, Matplotlib, and ipyleaflet:

jupyter lite build --XeusPythonEnv.packages=\
    numpy,\
    matplotlib,\
    ipyleaflet

Running the xeus-python kernel with the ipyleaflet widget in JupyterLite

More details can be found in the xeus-python-kernel GitHub repository.

What about the future?

This combination of JupyterLite and Mamba has the potential to open Jupyter to millions of additional users.
Given its scalability, ease of deployment, reproducibility, and accessibility, JupyterLite will be everywhere: countries, organizations, and schools that don’t have access to sovereign cloud infrastructure will be able to deploy Jupyter-based education platforms on servers that they truly own, without endangering the data of their students or becoming too reliant on resources that they do not control.

In the short term, we are working on the following “next steps”:

Mambalite: To support the installation of packages at runtime. Similar to Pyodide’s pip-lite, it will allow downloading packages at runtime.
Fortran: Compiling Fortran code with Emscripten is currently not supported, but it is necessary for key packages like SciPy. Pyodide relies on f2c, a Fortran-to-C converter, in conjunction with a set of patches to compile Fortran code with Emscripten. We are working on a more direct approach: compiling SciPy natively with LFortran.
Binderlite: Binder converts a repository of notebooks into an executable JupyterLab environment, making code immediately reproducible by anyone, anywhere. Emscripten-forge is the missing piece to build BinderLite, a version of Binder relying on JupyterLite instances instead of vanilla JupyterLab instances.
Rust/PyO3 support: We are working on integrating the work of the Pyodide team on Rust/PyO3 support in emscripten-forge. This will be important to build Rust extension modules like cryptography.

Credits

This was built upon the work of a much bigger crowd!

The Pyodide team

The Pyodide project was started at the Mozilla foundation by Michael Droettboom and is now maintained by Hood Chatham, Roman Yurchak, and Gyeongjae Choi.

The foundational work of the Pyodide project pioneered the use of Python in the browser and made all of the rest possible, from JupyterLite to this work.

The Emscripten team

Both Pyodide and emscripten-forge are built upon the Emscripten toolchain, which provides the foundational components to be able to meaningfully run WebAssembly programs in the browser.

The JupyterLite team

The JupyterLite project was started by Jeremy Tuloup, with significant contributions from Nick Bollweg and Martin Renou.

The Mamba Org team

The mamba ecosystem has been instrumental in making these developments possible. We use the Quetz open-source server for hosting the packages and the Boa tool to build them. In the mamba development team, we should highlight the work of Wolf Vollprecht, Johan Mabille, Joel Lamotte, and Andreas Trawöger.

The Xeus team

The xeus project was started by Johan Mabille and Sylvain Corlay. It is at the foundation of the JupyterLite integration and helped to get all the pieces together (Xeus, Mamba, Jupyter). We should especially credit the work of Martin Renou and Thorsten Beier on this integration with JupyterLite.

Acknowledgment

The work of Thorsten Beier, Johan Mabille, Martin Renou, Sylvain Corlay, Wolf Vollprecht, Joel Lamotte, and Andreas Trawoger at QuantStack was funded by Bloomberg.

About the Authors

Thorsten Beier

Thorsten Beier is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he graduated in computer science at the University of Heidelberg and worked at the EMBL. As an open-source developer, Thorsten worked on a variety of projects, from xeus and xtensor in C++ to inferno, kipoi, ilastik, and napari-splineit in Python.

Martin Renou

Martin Renou is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he studied at the French Aerospace Engineering School SUPAERO. He also worked at Logilab in Paris and Enthought in Cambridge. As an open-source developer at QuantStack, Martin worked on a variety of projects, from xsimd, xtensor, and xframe in C++ to ipyleaflet and ipywebrtc in Python and JavaScript.

Inspector JupyterLab

2022-04-11T11:50:00+00:00

JupyterLab provides multiple ways to improve your coding workflow: code highlighting, code completion, theming, debugger with rich variable rendering and more.

The JupyterLab inspector

The JupyterLab inspector is one of the ways to enhance your coding experience, it is a UI panel that provides contextual help while you are typing:

You can open the inspector using the Ctrl + I shortcut (or ⌘ + I on Mac).

With the Python kernel (ipykernel or xeus-python), this contextual help normally contains a text representation generated using the inspect Python module and the docstrings associated to an object. But there is a way to make it much nicer!

Go-Go-Gadget Docrepr

Docrepr is a Python package which renders docstrings into HTML using Sphinx, maintained by the Spyder team. IPython allows to use docrepr for code inspection, making it the perfect combination for a nice rendering of the contextual help in the inspector!

Thanks to the recent work on the jupyterlab-pygments extension, the docrepr output even respect the current JupyterLab theme for syntax highlighting!

Installation

First you will need to install the package (either with pip or mamba)

pip install docrepr jupyterlab_pygments

Or:

mamba install -c conda-forge docrepr jupyterlab_pygments

In order for IPython to use docrepr, you will need to execute the following in your Notebook (e.g. in the first cell):

ip = get_ipython()
ip.sphinxify_docstring = True
ip.enable_html_pager = True

This also can be set in your IPython configuration file located in ~/.ipython/profile_default/ipython_config.py:

c = get_config()

c.InteractiveShell.sphinxify_docstring = True
c.InteractiveShell.enable_html_pager = True

You are all set! The JupyterLab inspector will now render HTML representations of the contextual help.

Acknowledgments

Docrepr has a long history, it originates from the Sphinxify tool of the Sage project that was created back in 2009 by Tim Dumol. In 2010 Carlos Córdoba used it to power Spyder’s help pane and in 2015 he extracted that code and created the docrepr Python package, so that other projects could benefit from it. It was later integrated in IPython by Sylvain Corlay. In 2021 C.A.M. Gerlach, Ahmed Fasih and myself updated the package to support the latest Sphinx version.

My work on this project at QuantStack was funded by Bloomberg.

About the Author

My name is Martin Renou, I am a Scientific Software Engineer at QuantStack. Before joining QuantStack, I studied at the aerospace engineering school SUPAERO in Toulouse, France. I also worked at Logilab in Paris, France and Enthought in Cambridge, UK. As an open-source developer at QuantStack, I work on a variety of projects, from xtensor and xeus-python in C++ to ipyleaflet and bqplot in Python and JavaScript/TypeScript, I am also the author of several JupyterLab extensions.

Jupyter Everywhere

2022-03-15T15:22:00+00:00

Easily embed a console, a notebook, or a fully-fledged IDE on any web page.

In a previous blog post, we announced JupyterLite, a JupyterLab distribution that runs entirely in the web browser, backed by in-browser language kernels.

By default, JupyterLite ships with a Python kernel powered by Pyodide and IPython, bringing a wide variety of features from code completion to interactive visualizations.

The latest releases of JupyterLite now ship with a REPL application by default, that you can embed in any website.

Embed a live Python console on your website 🚀

Do you want to add an interactive code console to your website, so your visitors can run Python code directly in their browser without installing anything?

Let’s say you already have a static website up and running. This could for example be a Jekyll blog. With the JupyterLite REPL, you can embed the interactive console in your website with something as simple as the following code snippet:

<iframe
  src="https://jupyterlite.github.io/demo/repl/index.html?kernel=python&toolbar=1"
  width="100%"
  height="500px"
>
</iframe>

And there you have it, a live Python REPL embedded in your blog! 🎉

An example of embedding a live Python console in a Jekyll blog.

This example relies on the publicly available demo website deployed to GitHub Pages. However we recommend setting up your own JupyterLite deployment, so you can have full control and use custom configuration and extensions (see the Deploying your JupyterLite website section below).

Powering the NumPy documentation 🐍

The NumPy project had already been using an interactive console on the numpy.org documentation website. The previous console was powered by Thebe and mybinder.org. While this gave great flexibility and a way for users to try NumPy without installing anything on their machine, it required starting a new Jupyter Server on Binder for each user, and then waiting for a kernel to start before being able to type some code.

This setup worked for a while but started to become more difficult to maintain and operate.

With the JupyterLite-powered Python REPL, numpy.org is now able to provide an interactive code console and let anyone try NumPy in their browsers. This considerably reduces the number of resources needed and allows for a smoother and snappier user experience.

The JupyterLite REPL on numpy.org

The REPL is currently based on the JupyterLab Code Console, which gives a familiar “look and feel” to Jupyter users. Other user interfaces such as a Single Executable Cell are also being considered for the next version of the REPL.

Try Jupyter 🟠

Another recent adopter of the JupyterLite stack is the official Jupyter website.

try.jupyter.org has been using the public-facing mybinder.org deployment to let users try the different Jupyter subprojects, such as Voilà and the Xeus-based kernels.

This setup has been working nicely for many years. However, the Binder project recently faced funding issues, which drastically reduced the overall capacity of the Binder federation. This means fewer resources are available to users for their projects, and this also impacted the Try Jupyter website.

To mitigate this, we decided to create a custom JupyterLite website and use it for some of the demos on Try Jupyter. Users can then continue to try some of the Jupyter interfaces in their browsers without installing anything on their machines. As a result, the JupyterLab and Jupyter Notebook demos now point to the new JupyterLite deployment.

Launching JupyterLite from try.jupyter.org

The “Try Jupyter with JupyterLite” deployment also includes the jupyterlab-tour extension, offering a user-friendly tour of the Jupyter interface to newcomers.

Deploying your JupyterLite website 💡

Contrary to a regular Jupyter deployment, JupyterLite can be served as a simple static website without running a Python server. This makes it simpler to deploy, and cheaper to operate.

Below are some examples for deploying your own JupyterLite and Python REPL.

Deploy to GitHub Pages

GitHub Pages is one of the simplest ways to host a JupyterLite website.

This is what the demo repository available at https://github.com/jupyterlite/demo does by default. It lets you bootstrap your JupyterLite website with a few clicks, and deploy it to GitHub Pages within a couple of minutes.

Creating a JupyterLite website with just a couple of clicks

After a few minutes, your website will be ready and you can then embed your live Python console with the following snippet:

<iframe
  src="https://yourhandle.github.io/my-custom-deployment/repl/index.html?kernel=python&toolbar=1"
  width="100%"
  height="500px"
>
</iframe>

The JupyterLite REPL running on GitHub Pages

Deploy to Vercel or Netlify

Hosted platforms like Vercel and Netlify are good options to deploy a static JupyterLite website.

The REPLite project is an example deployed to Vercel, based on the following repository with some custom configuration: https://github.com/jtpio/replite

The Python REPL can be embedded with an IFrame:

<iframe src="https://replite.vercel.app/repl?kernel=python&toolbar=1" width="100%" height="100%">
</iframe>

Here we use the ?kernel=python URL parameter to automatically choose the Python kernel on startup.

Deploying to ReadTheDocs using the Sphinx extension

Going the extra mile, jupyterlite-sphinx brings the power of JupyterLite to your Sphinx documentation. It automatically creates a JupyterLite deployment in your documentation website and provides some utilities for using that deployment easily.

If you are developing software, it’s a very convenient tool to let your users test your library directly on the documentation page!

This is also really useful for Jupyter users who want to easily share their work on readthedocs.org, GitHub Pages, or any other host that supports Sphinx documentation.

Installation

You can install jupyterlite-sphinx with pip:

pip install jupyterlite-sphinx

Then add the extension to your conf.py file:

extensions = [
    'jupyterlite_sphinx',
    # And other sphinx extensions
    # ...
]

And that’s it! jupyterlite-sphinx will automatically deploy a JupyterLite website when building your docs with Sphinx.

Usage

jupyterlite-sphinx provides multiple Sphinx directives for embedding Python consoles and custom Notebooks in your documentation:

To embed a Python REPL similar to the NumPy.org one:

.. replite::
   :kernel: python
   :theme: JupyterLab Light
   :width: 100%
   :height: 600px

    print('Hello from a JupyterLite console!')

Embedding the JupyterLite REPL

To embed a full Notebook:

.. retrolite:: my_notebook.ipynb

An interactive Jupyter Notebook on the ipycanvas documentation

Finally, you might also want to embed the full JupyterLite UI:

.. jupyterlite::

Note that the notebooks are saved in the browser local storage, so any work done on those Notebooks can be retrieved later when coming back to the web page with the same browser.

Documentation

You can find the jupyterlite-sphinx documentation with live examples following this link:

jupyterlite-sphinx — JupyterLite sphinx extension documentation

Example

You can find an example of jupyterlite-sphinx being used on ReadTheDocs here:

ipycanvas: Interactive Canvas in Jupyter — ipycanvas documentation

More examples

JupyterLite can be deployed on more platforms than just the ones mentioned above. Pretty much anything that can serve static files should work!

Feel free to check out the documentation to learn more about deploying your JupyterLite website on other platforms: https://jupyterlite.readthedocs.io/en/latest/deploying.html#hosted

Jupyter Everywhere 🌐

With JupyterLite gaining rapid adoption on widely visited websites such as numpy.org and try.jupyter.org, we envision Jupyter being adopted on more websites and documentation over the next months.

We hope to bring interactive computing with Jupyter to even more people than before and make it more accessible by lowering the barrier of entry.

Because JupyterLite can easily be extended with JupyterLab extensions, we also expect more Jupyter-based deployments and applications to flourish, making good reuse of the existing components that constitute the vibrant Jupyter ecosystem 🌸

Jupyter is language agnostic and more kernels are now available in JupyterLite, for example for Lua and SQLite based on the Xeus framework. Soon Jupyter will also power the documentation and websites of other languages, not just Python.

About the authors

Martin Renou is a Scientific Software Engineer at QuantStack and a Jupyter Distinguished Contributor. Martin works on a variety of projects, from xtensor and xeus-python in C++ to ipywidgets, ipyleaflet and bqplot in Python and TypeScript.

Jeremy Tuloup is a Scientific Software Engineer at QuantStack and a Jupyter Distinguished Contributor. Maintainer and contributor of JupyterLab, Jupyter Notebook, JupyterLite, Voilà, and projects within the Jupyter ecosystem.

Abracadabra! Bringing the magics to xeus-python

2021-02-18T13:30:00+00:00

Last year, we set ourselves to implement a visual debugger for JupyterLab. This endeavor required major developments in the JupyterLab front-end, in core-Jupyter protocols, and on the kernel side (the part of the Jupyter infrastructure responsible for executing the code).

For kernel-side development, we decided to start with the xeus-python kernel, a lightweight implementation of a Jupyter kernel for the Python programming language. Based on xeus, xeus-python has a flexible concurrency model that was required to e.g. add breakpoints while executing code.

Unfortunately, xeus-python did not provide all ipykernel features (magics, Matplotlib support, etc.). Furthermore, many notebooks depend on IPython, as they import it explicitely or make use of the IPython configuration system.

Today, we are proud to announce that xeus-python supports 100% of the IPython magics! This was achieved by leveraging the core IPython package. This is getting us closer to feature parity with ipykernel.

Magics

xeus-python now supports all magics that IPython provides and even user-defined magics!

Support for builtin IPython magics and user-defined magics

Matplotlib

Most Matplotlib back-ends are now supported by xeus-python, allowing you to show static plots with the inline back-end or interactive plots with ipympl in your Notebook:

Matplotlib inline back-end and ipympl interactive back-end

Extending

IPython has a rich configuration system that you can tweak in order to get an enhanced Notebook experience. Xeus-python now supports any configuration you setup for IPython:

Automatically import NumPy in the IPython settings

Visual Debugging

The latest JupyterLab version introduced a visual debugger in its interface. xeus-python was the first Jupyter kernel to add support for it!

Stepping into Python code in JupyterLab with the visual debugger

xeus-python is not the only Jupyter kernel that supports debugging anymore: xeus-robot is a xeus-based Jupyter kernel for the RobotFramework language that supports the JupyterLab visual debugger.

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Installation

You can install the latest xeus-python version using mamba or conda:

mamba install xeus-python -c conda-forge

conda install xeus-python -c conda-forge

You can also compile it yourself, instructions can be found in the repository:
https://github.com/jupyter-xeus/xeus-python

Acknowledgments

My work on xeus and xeus-python at QuantStack was funded by Bloomberg.

About the Author

Robotic Process Automation with JupyterLab

2021-01-18T10:36:00+00:00

Robotic Process Automation (RPA) differs from classical automation tools in that the actions to automate can be developed by observing a user perform a task in a graphical user interface, across multiple applications.

It is a means to lower the entry barrier of process automation and enable the use of tools that don’t provide a programmatic interface.

Most typically, RPA developers will use a mixed approach between textual programming and performing actions manually. The resulting programs are typically called software robots. Therefore, interactive computing tools like Jupyter are a natural environment for RPA, as the interactive nature of Jupyter allows for quick iterations and trial-and-errors when developing such robots.

While many RPA tools are commercial software, Robot Framework and the tooling developed by Robocorp provide an open-source RPA programming language, with a high-level syntax, extensible with Python plugins. It has a rich ecosystem of libraries and tools that are developed as separate projects.

Robot Framework and Project Jupyter

Today, we are happy to announce the first release of xeus-robot, a Jupyter kernel for Robot Framework based on xeus, supporting the new JupyterLab 3.0 visual debugger, auto-completion, and much more!

But before we dive into xeus-robot, we should recognize the earlier work by Nick Bollweg and Asko Soukka, who developed two Jupyter kernels for Robot Framework, irobotframework, and robotkernel, and gave an amazing talk together at RoboCon in 2019!

The motivation for us to reboot this effort with a kernel based on xeus was to enable the JupyterLab Visual Debugger for this kernel. This requires a different concurrency model than that of ipykernel, which underlies both irobotframework and robotkernel. In the end, we were able to provide the same features and more, including e.g. code completion in Python cells, debugging etc.

Diving into Xeus-robot

xeus-robot is a reboot of the already existing robotkernel, based on xeus.

Like most language kernels, xeus-robot supports code completion, inspection, error handling, etc. It also allows using Python cells to define custom robot keywords in Python, those Python cells support code completion as well.

Code Completion in Robot Framework

By using the libraries robotframework-seleniumlibrary and robotframework-seleniumscreenshots, you can even complete the selection of elements on the page you are currently testing!

Code completion with an action of the user in the UI.

The %%python cell magic makes it possible to extend Robotframework with Python modules in the notebook.

Extending RobotFramework with Python, and code completion in Python cells

Widget-based UIs are provided to test Robotframework “keywords”.

Testing Robot Framework “keywords” with Jupyter widgets

Last but not least, xeus-robot comes with full support for the JupyterLab Visual Debugger! After the xeus-python kernel, it is the second Jupyter kernel to support the Jupyter Debugger Protocol! We hope that many more will come.

You can set breakpoints, step in defined keywords (the equivalent of functions), inspect variables, and see the callstack, as shown below.

The JupyterLab Visual Debugger in action with Robot Framework

Installing xeus-robot

Xeus-robot is available for all platforms on conda-forge, and can be installed with conda or mamba.

mamba install xeus-robot -c conda-forge

The jupyterlab-robotmode package, which provides JupyterLab syntax highlighting for Robot Framework will also be installed as a dependency.

For your conda installation, we recommend starting from mambaforge or miniforge which are available for download here, and default to the conda-forge channel (making the -c conda-forge argument unnecessary).

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Acknowledgments

The work on xeus-robot by QuantStack was funded by Robocorp, and is part of their initiative to create an open-source RPA ecosystem. Beyond the xeus-robot kernel, Robocorp also funds the integration of Robot Framework with Visual Studio Code, RPA Framework, and other development to push the Robot Framework project forward.

The implementation of the debugger in xeus-robot relies on robotframework-lsp by Fabio Zadrozny and we want to thank him for his help in integrating it in xeus-robot.

About the authors

Martin Renou is a scientific software developer at QuantStack. He is the creator of the xeus-python and xeus-robot kernels.

Johan Mabille is a scientific software developer at QuantStack. He is a co-author of the xeus project, and developed the debugger extensions to xeus-python and xeus-robot. He also co-authored the front-end for the JupyterLab visual debugger.

ipygany: Jupyter into the third dimension

2020-10-14T09:51:00+00:00

Scientific visualization in the Jupyter notebook

From Paraview to Mayavi, there are multiple solutions for data analysis on 3D meshes on the desktop. Most of these tools provide high-level APIs that can be driven with a scripting language like Python. For example, one could control Paraview from a Jupyter Notebook. But this is not ideal as it relies on a desktop application for the rendering, which prevents using tools like MyBinder.

Nowadays, most scientists run their computation on the cloud, and they need tools for interacting and analyzing with their data.

There are already some solutions that are more integrated into Jupyter:

ipyvolume is a WebGL-based 3D plotting library for Jupyter. It has many features including multi-volume rendering.
K3D-jupyter helps you create 3D plots backed by WebGL with high-level API (surfaces, isosurfaces, voxels, mesh, cloud points, vtk objects, volume renderer, colormaps, etc).
itkwidgets is a tool for visualizing images, point sets, and meshes in 2D and 3D in Jupyter. It works by doing the rendering on the back-end and by streaming the frames to the front-end.
ipyvtk-simple is a Jupyter library for interfacing with any Python vtkRenderWindow. It relies on ipycanvas for streaming the frames to the front-end.

We needed a Paraview-like experience for Jupyter. We could provide this experience by relying on the vtk library in Python, but this means that every time you want to apply a new filter like warp-by-scalar, the Python back-end needs to send the filtered mesh to the front-end for display. This is far from ideal, as it might be hundreds of megabytes to download for every roundtrip to the back-end.

itkwidgets and ipyvtk-simple fix this issue by not sending the mesh to the page, instead, the rendering is done on the back-end and streamed to the user. This solution is, in a way, similar to using Paraview using a vnc solution. It works fine as long as you have a fast and low latency connection to the Jupyter server, and this solution scales properly with the mesh size, as the amount of data sent to the user is the same whether you analyze a fine or a coarse mesh.

Solutions like ipyvolume and K3D-jupyter can be backed by the Python vtk library (or by PyVista), but again, this means doing the mesh filtering in Python and sending the filtered meshes to the page for every change.

Today we are proud to announce ipygany! ipygany is a Jupyter widget that aims at bringing a Paraview-like experience to the webpage. With ipygany, you only send your mesh data to the front-end once, and effects such as mesh warping, contour computation, threshold filtering are directly done in the front-end and most-typically with the GPU.

Introducing ipygany

ipygany is a new interactive widgets library that allows you to visualize and analyze volumetric data in the Jupyter Notebook.

Whether your data comes from a VTK file or NumPy arrays, ipygany allows you to dynamically load your data, display them in the Notebook, and apply different kinds of visual effects on it.

ipygany provides a set of effects inspired by Paraview:

IsoColor: apply color-mapping to your mesh.
Warp: deform your mesh given a 3-D input data (e.g. displacement data on a beam)
WarpByScalar: deform your mesh given a 1-D input data (e.g. terrain elevation)
Threshold: only visualize mesh parts inside a range of data (e.g. 222 K≤ temperature ≤ 240 K)
IsoSurface: only visualize the surface where the mesh respects a data value (e.g. pressure == 3 bar)
Glyph effects like PointCloud
Water visualization
And there’s more to come!

Most of those effects are computed on the GPU only! Which makes them really fast. For example, changing the deformation factor of the Warp effect only sends one floating-point number to the GPU, and the GPU will know how to re-render the mesh (using shaders) according to the new factor value, this update is virtually instantaneous. Changing the warp factor value is technically as fast as moving the camera position, it only requires rendering a new frame.

We strive to use efficient algorithms for better performances, especially for computation that cannot be done with the GPU.

WarpByScalar: completely computed on the GPU

Effects can be easily combined for highlighting important parts in your mesh. For example, you can easily cut your mesh using the Threshold effect then apply a Warp effect for visualizing a deformation on the result.

Combining a Threshold with a Warp

All those effects are interactive widgets, they are stateful objects that you can dynamically update from Python or using widgets like sliders, text inputs, etc.

Your mesh is also an interactive widget: you can dynamically update your data, which is very useful when your data changes through time.

Visualizing an animation from two viewpoints

If you work with fluid dynamics, we even provide refractive/reflective effects and water caustics computation for nice looking visualization:

If you do Water simulation, ipygany also allows you to render you water with reflective/refractive effects and it even computes light caustics!

Installation

You can install ipygany with conda or mamba:

mamba install -c conda-forge ipygany

conda install -c conda-forge ipygany

Or you can install it with pip:

pip install ipygany

If you use JupyterLab you’ll need to install the labextension (not needed with the coming JupyterLab v3):

jupyter labextension install @jupyter-widgets/jupyterlab-manager ipygany

Documentation

You can find the documentation following this link:

https://ipygany.readthedocs.io

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Acknowledgement

This work is led at QuantStack and founded by ERDC.

About the Author

SlicerJupyter: a 3D Slicer kernel for interactive publications

2020-07-08T16:29:00+00:00

Use Jupyter and 3D Slicer kernel to implement biomedical data processing workflows in a notebook.

The Jupyter ecosystem is a powerful platform for exploratory computational science, and now it can connect with some of the deep and rich domain-specific desktop applications that have decades of feature development already invested in them. With the integration of 3D Slicer with Jupyter through the xeus-python’s interpreter, we demonstrate how a Qt-based graphical desktop application with 3D visualization provided by Visualization Toolkit (VTK), image processing provided by the Insight Toolkit (ITK), can be used through a Jupyter notebook. This approach is available on the SlicerJupyter GitHub repository and could be extended to other applications that embed Python, such as Blender, FreeCAD, or ParaView.

This xeus-python integration is beneficial both for the Jupyter ecosystem and desktop applications. Features that have been developed for decades for desktop applications become readily available for Jupyter users without learning a new working environment or redeveloping features. For a desktop application, the Jupyter notebook can serve as a way to create reproducible data processing workflows, scientific publications, and maintainable tutorials without requiring local software installation. From Jupyter, you can now quickly create simple medical imaging applications with extremely rich interactivity from 3D Slicer. Read below for a discussion of the features available and the history of the project.

Powerful Medical Imaging Capabilities Available Through Jupyter

3D Slicer (or Slicer for short) is a C++ desktop application that uses Qt, ITK, and VTK libraries for visualization and medical image analysis. Slicer’s embedded Python interpreter makes all its features accessible with the Python programming language. Slicer has a simple built-in console to run Python commands interactively and can run Python scripts from files, but these are not as convenient as cell-base interactive notebooks, which have become popular among data scientists and researchers in recent years.

By integrating the xeus-python kernel, we can use a Slicer process as a Jupyter kernel. xeus-python leverages the xeus C++ implementation of the Jupyter kernel protocol. xeus-python is an alternative to ipykernel, which can be used with a vanilla CPython interpreter, interfacing to standard CPython Jupyter widgets like itkwidgets, but it can also be coupled with custom interpreters and GUI event loops, like the Slicer interpreter and its Qt event loop. This allows you to represent a complete scene in Medical Reality Markup Language, MRML, Slicer’s internal data structure. The kernel exposes the full medical imaging API and representation of your data in a meaningful way for Python developers, allowing access through standard Python ecosystem formats such as pandas dataframes and NumPy arrays in the Notebook.

Interactivity Levels

You can also use Jupyter interactive widgets (sliders, buttons, etc.) to control Slicer, modify data, or adjust processing and visualization parameters. Interactivity can be implemented at different levels.

Level 1: Standard Jupyter widgets display application specific objects by automatic conversion of application-specific data objects to standard Python objects. For example, Slicer markup fiducial lists are displayed as a nicely formatted table and model nodes are rendered as 3D objects.
Level 2: Static image widgets display content that the desktop application renders. These widgets can be made interactive by modifying data and rendering parameters using additional standard widgets. This makes rich visualization capabilities — sophisticated rendering various data types, rendering of very large data sets, etc. directly available in Jupyter.
Level 3: Dynamic viewer widgets display 2D and 3D views rendered by the desktop application. Mouse and keyboard events are forwarded to the desktop application that allows zooming/rotating views, and to utilize all 3D interactions implemented in the desktop such as placing annotations, making measurements, or segmenting images the same way as if it was done on the desktop appication’s screen. This is implemented in the Slicer Jupyter kernel using ipycanvas and ipyevents packages.
Level 4: Full desktop graphical user interface integration. Users can see parts of the application window rendered in notebook cells, including standard desktop widgets (sliders, menus, etc.). It is implemented using noVNC and TigerVNC in Slicer Jupyter. This is particularly useful when the application runs on a remote server.

Video demonstrating how to run 3D Slicer using Binder

These interactive tools allow developers to implement complete data processing workflows in a notebook, even if certain steps require manual user inputs such as segmenting 3D regions or setting seed points.

Try it online!

Since Jupyter notebooks can be used from any web browser, it can essentially turn any desktop application to a web application. By setting up a remote Jupyter server, users do not have to install anything on their computers. We have set up a demonstration of this using Binder (www.mybinder.org) that anybody can try at https://mybinder.org/v2/gh/Slicer/SlicerNotebooks/master.

Click on the binder image to launch the demo

The docker image that installs and configures Slicer and all dependencies (ipycanvas, ipyevents, VNC, etc.) is available at https://github.com/Slicer/SlicerDocker/tree/master/slicer-notebook. For deployment to non-technical users, applications can be deployed using Voilà (https://voila.readthedocs.io/), which only shows relevant content and interactive widgets, so the notebook looks like a simple dynamic web page.

The current implementation is already stable and offers a wide range of features, but there is still room for design and performance improvements. For example, we could not implement fully automatic conversion of application-specific data objects to displayable Python objects (due to complex implementation of display hooks); xeus-python debugger’s threading model needs to be improved to allow using it without locking the application’s main thread; and dynamic viewer widget’s performance (level 3 interaction) could be optimized to achieve higher refresh rates.

History of Slicer and this integration

Built over two decades with support from the NIH and a worldwide open source developer community, 3D Slicer is a unique, multi-platform desktop application for analysis, integration, and visualization of medical images that is heavily used by researchers globally for basic and applied research in a wide range of topics. The 3D Slicer Community includes physician-scientists with disease-specific knowledge of clinical challenges, computer scientists and physicists who develop novel algorithms, imaging informatics researchers, software engineers with the ability to understand clinical problems and create reliable tools, and application engineers with the multidisciplinary skills to deploy these tools in a range of cancer research settings. Slicer is maintained by Kitware, Inc., and the NAMIC consortium, and has an active open source software community. Slicer is used in hospitals and by researchers, with more than 10k academic citations and more than 150k downloads in the last year alone.

Click on the image to download 3D Slicer

It can be used for image processing workflows on 2D, 3D, and 4D images. What makes Slicer so useful is its huge set of community contributed modules that extend its functionality, as well as its ability to read DICOM and a wide array of exotic file formats.

Slicer has been scriptable in Python for well over a decade, but a robust SlicerJupyter extension is born from significant development effort by the community. The idea for this integration dates back to SciPy in 2014, when Jean-Christophe Fillion-Robin of Kitware organized a sprint intended to integrate Slicer and an IPython notebook, motivated by the dream of creating interactive and fun tutorials for Slicer. Mike Sarahan and Jean-Christophe created this proof of concept https://github.com/commontk/QEmbedIPython#qt-embed-ipython, but it was far from usable. In 2015 Matt McCormick of Kitware, created the SlicerDocker repository to support headless builds and rendering in a Docker image. Then in June 2018, while attending the Slicer Project Week, Andras Lasso (Queen’s University) and Jean-Christophe learned about Xeus, a C++ implementation of the Jupyter kernel protocol developed by QuantStack that would help streamline the integration of Slicer with Jupyter. To support this effort, Andras and Jean-Christophe created the Slicer/SlicerJupyter GitHub repository. They also contributed changes to Xeus to support this new integration paradigm where the event loop of the kernel is driven by a Qt-based Desktop application (see here). Building on this foundation, Isaiah Norton, then working at Brigham and Women’s Hospital, contributed additional improvements like a better auto-completion using jedi (see https://github.com/Slicer/SlicerJupyter/pull/12) as well as integration with Binder. More recently, Jean-Christophe and Sylvain Corlay (QuantStack) met after the Slicer project week while attending SciPy in Austin. Following the creation of a new project called xeus-python (started by Martin Renou at QuantStack), we took the integration of Jupyter and Slicer to the next level by adding support for improved interactive use and MRML data node visualization directly in the notebook.

About the authors

Alphabetically ordered

Sylvain Corlay is the founder and CEO of QuantStack, and a core Jupyter developer. He co-authored xeus and xeus-python.

Sylvain Corlay

Jean-Christophe Fillion-Robin is an open-source enthusiast, original author of the SlicerJupyter extension and a principal engineer at Kitware Inc where he leads the development of “3D Slicer” based commercial applications. J-Christophe also maintains scikit-build, an improved build system generator for CPython C/C++/Fortran/Cython extensions.

Jean-Christophe Fillion-Robin

Mike Grauer is a Technical Leader on the data and analytics team at Kitware. He is specialized in building scalable server-side processing frameworks that enable scientific workflows over web platforms.

Mike Grauer

Andras Lasso is an original author of the SlicerJupyter extension, Senior Research Engineer and Associate Director of the Laboratory for Percutaneous Surgery at Queen’s University.

Andras Lasso

Matt McCormick is an open source, medical imaging researcher working at Kitware Inc. Matt is an active, contributing member of scientific open source software efforts such as the Insight Toolkit (ITK) and scientific Python (SciPy) communities, and maintains the Jupyter 3D widget, itkwidgets.

Matt McCormick

Isaiah Norton is a Senior Software Developer at TileDB, Inc. with experience in digital pathology and image-guided surgical navigation.

Isaiah Norton

Steve Pieper is a Chief Architect and active developer of the 3D Slicer application for well over a decade. He is CEO of Isomics, Inc, where he uses a range of software technologies to perform medical imaging research with leading universities and companies.

Steve Pieper

Martin Renou is a scientific software developer at QuantStack. He is the original author of xeus-python, the xeus-based Python kernel, and contributed to the new concurrency model used for the debugger.

Martin Renou

Mike Sarahan is a software engineer at RStudio, PBC working on bringing language ecosystems together. He is passionate about making software work for data scientists in ways that are easy to maintain and improve.

Mike Sarahan

ipycanvas: A Python Canvas for Jupyter

2019-10-25T12:48:00+00:00

As you may already know, the Jupyter Notebook and JupyterLab are Browser-based applications. Browsers are incredibly powerful, they allow you to swap rich and interactive graphical interfaces containing buttons, sliders, maps, 2D and 3D plots and even video games in your webpages!

All this power is readily made available to the Python ecosystem by Jupyter interactive widgets libraries. Whether you want to create simple controls using ipywidgets, display interactive data on a 2D map with ipyleaflet, plot 2D data using bqplot or plot volumic data with ipyvolume, all of this is made possible thanks to the open-source community.

One powerful tool in the Browser is the HTML5 Canvas element, it allows you to draw 2D or 3D graphics on the webpage. There are two available APIs for the Canvas, the Canvas API which focuses on 2D graphics, and the WebGL API which uses hardware acceleration for 3D graphics.

After some discussions with my work colleague Wolf Vollprecht, we came to the conclusion that it would be a great idea to directly expose the Canvas API to IPython, without making any modification to it. And that’s how we came up with ipycanvas!

ipycanvas: Exposing the Canvas API to IPython

ipycanvas exposes the Canvas API to IPython, making it possible to draw anything you want on a Jupyter Notebook directly in Python! Anything is possible, you can draw custom heatmaps from NumPy arrays, you can implement your own 2D video-game, or you can create yet another IPython plotting library!

ipycanvas provides a low-level API that allows you to draw simple primitives like lines, polygons, arcs, text, images… Once you’re familiar with the API, you’re only limited by your own imagination!

Draw image from NumPy array

Implementation of the Game Of Life

Draw millions of particles

Draw custom sprites

A line plot drawn with ipycanvas, with a slider that changes it

Make your own plotting library for Jupyter fully in Python!

Using Matt Craig’s ipyevents library, you can add mouse and key events to the Canvas and react to user interactions.

If you have a GamePad around, you can also use the built-in Controller widget and make your own video-game in a Jupyter Notebook!

Documentation

Check-out the ipycanvas documentation for more information: ipycanvas.readthedocs.io

Github repository

Give it a star on Github if you like it! github.com/martinRenou/ipycanvas

Try it online!

You can try it without the need of installing anything on your computer just by clicking on the image below:

Installation

Note that you first need to have Jupyter installed on your computer. You can install ipycanvas using pip:

pip install ipycanvas

Or using conda:

conda install -c conda-forge ipycanvas

About the author

My name is Martin Renou, I am a Scientific Software Engineer at QuantStack. Before joining QuantStack, I studied at the aerospace engineering school SUPAERO in Toulouse, France. I also worked at Logilab in Paris and Enthought in Cambridge, UK. As an open-source developer at QuantStack, I worked on a variety of projects, from xtensor and xeus-python in C++ to ipyleaflet and ipywebrtc in Python and Javascript.

Interactive GIS in Jupyter with ipyleaflet

2019-09-24T22:54:00+00:00

As Jupyter grew in popularity, a broad ecosystem of visualization packages based on Jupyter widgets has been developed, bringing even more interactivity to the Jupyter world.

In this article, we dive into Jupyter Interactive Widgets and the ipyleaflet package, an interactive maps visualization system for Jupyter.

A non-interactive map.

Jupyter Widgets

Jupyter Interactive Widgets are “special objects” that can be instantiated by the user in their code and result in a counterpart component being created in the front-end.

The core ipywidgets package provides a collection of controls that Jupyter users can use to build simple UIs as part of their notebooks (sliders, buttons, dropdowns, layout components).

Basic ipywidgets controls.

More than a collection of controls, it provides a framework upon which a large ecosystem of components has been built, allowing notebook authors to capture user inputs in very diverse ways.

Popular libraries built upon interactive widgets include

bqplot, a 2-D plotting system for Jupyter,
ipyvolume, a 3-D plotting package based on WebGL and ThreeJS,
PythreeJS, a 3-D scene description package exposing a large part of the ThreeJS API to Jupyter,
ipyvuetify, a large collection of VuetifyJS components exposed to Jupyter,
ipywebrtc, a library exposing the features of the WebRTC protocol to Jupyter kernels,
beakerx, a collection of widgets, extensions, and kernels for Jupyter,

and many more… This list is not comprehensive and dozens of other widget packages have been developed.

Key aspects of Jupyter widgets include:

Bidirectionality: Widgets are not just meant for display but can also be used to capture user inputs, which can then trigger new computation. Notebook authors can compose sophisticated applications including a variety of components from different packages.
Language Agnosticism: Built upon the Jupyter ecosystem, the interactive widget protocol used for the synchronization between the kernel and the front-end is well-specified and can be implemented for any kernel.
Back-ends for other languages than Python already exist, such as for C++ (with the xeus-cling Jupyter kernel), and languages of the JVM such as Clojure or Groovy (with the beakerx kernels).
Extensibility: Jupyter widgets are not meant as a monolithic system with one and only one way to achieve a specific task. We strive to provide a foundational layer allowing third-party widget authors to be as inventive as possible.

A common pattern for Jupyter widget packages has been to bring the capabilities of popular JavaScript visualization frameworks to Jupyter with a bridge based on ipywidgets. This is the case for the ipyleaflet package, as well as pythreejs and ipyvuetify.

Another use case is the development of ad hoc controls that are not necessarily relevant for a mainstream visualization package, but may be specific to a scientific field. An example is the ipymesh project by Chris Kees which can be used to draw PSLG (planar straight-line graphs) in the Jupyter notebook.

ipyleaflet

ipyleaflet is a Jupyter - LeafletJS bridge, bringing mapping capabilities to the notebook and JupyterLab.

Built as a bridge between the LeafletJS package and Jupyter, the ipyleaflet API maps to that of LeafletJS, bringing most of the core features of the package to Jupyter, and enabling a few popular LeafletJS extensions. A small difference is that following the Python coding style, ipyleaflet makes use of snake_case instead of CamelCase for attribute names.

ipyleaflet features

The main components to the library are layers and controls, respectively items to be displayed on the map, and interactive widgets overlayed on the map area for greater interactivity.

The first thing for which you may want to change the default value are the zoom level, the position, or the base layer for the map.

Changing the basemap layer in an ipyleaflet map.

Maps can be interactively edited in the Jupyter notebook, by dynamically changing or adding layers. In this screenshot, we add a custom layer including a GeoJSON dataset.

Note: An alternative layer to GeoJSON is GeoData, which lets the user load the data in the form of a GeoPandas dataframe instead of raw GeoJSON.

Adding a GeoJSON dataset to an interactive map.

A number of simple primitives are available such as markers and heatmaps. In the following screencast, we show how primitive properties can be linked with other widgets, and used as means to take user input on a map:

Linking properties of ipyleaflet primitives to other Jupyter widgets.

The splitmap control can be used to compare to different set of ipyleaflet layers at the same location.

The splitmap control.

Another interesting layer is the velocity layer which can be used to display wind velocity data. This control can take data in the form of an xarray dataset.

The velocity layer.

More classical visualization tools are also available, such as choropleths.

A choropleth layer.

JupyterLab Integration with the Sidecar and Theming Support

ipyleaflet is well integrated with JupyterLab

ipyleaflet controls make use of the JupyterLab themes for coloring so that they don’t stand out when using e.g. a dark theme.

The support for JupyterLab themes in ipyleaflet.
ipyleaflet can be used in combination with the JupyterLab sidecar widget.

Using the sidecar widget in JupyterLab to display a map aside of the notebook.

Together with the sidecar, a map can be programmatically added to the right-side toolbar of the JupyterLab application, and interactively edited in the notebook. This prevents the back-and-forth scrolling often required to see how changes are reflected visually.

The workflow enabled by ipyleaflet in combination with the sidecar is similar to that of the geonotebook project by Christopher Kotfila, Jonathan Beezley, and Dan LaManna from Kitware).

The geonotebook (which was based on the classic notebook) provided a similar workflow to the lab sidecar.

A more advanced example

Combined with other widget libraries such as bqplot or the core ipywidget package, ipyleaflet users can easily compose more complex applications and dashboards. In the following screencast, we explore the wealth-of-nations dataset with a leafletmap, a bqplot line chart and a dropdown widget:

Exploring the wealth-of-nations dataset with ipyleaflet, bqplot and core ipywidgets.

Trying ipyleaflet online with mybinder

If you would like to try out ipyleaflet now, it is possible thanks to the binder project. Just click on the image below!

Interactive GIS in C++: xleaflet

As mentioned earlier, interactive widgets back-ends for other programming languages have be implemented. There is a C++ back-end for ipywidgets: xwidgets which is the building block for creating other C++ widgets back-ends.

xleaflet is the C++ - LeafletJS bridge that exposes almost the same API as ipyleaflet, only that you use it from a C++ interpreter! It is based upon xwidgets which brings the bidirectional communication with the front-end.

You can learn more about the xeus-cling Jupyter kernel, xwidgets and xleaflet by reading the following blogpost.

xleaflet is the C++ backend to the jupyter-leaflet integration.

Deploying ipyleaflet-based dashboards with Voilà

Voilà is a tool that turns Jupyter notebooks into standalone dashboards. Built upon the Jupyter stack, it inherits the language agnosticism of the ecosystem, and can be used to produce standalone applications based on ipyleaflet.

A companion project to Voilà is the Voilà gallery project, a public facing set up of JupyterHub serving Voilà dashboard. It is kindly hosted by OVH. You can check out the Voilà gallery at URL https://voila-gallery.org.

For more resources about voilà, check out

the original announcement of the project: And Voilà!
and for the gallery: A Gallery of Voilà Examples.

If you check out the Voilà gallery, don’t miss Jeremy Tuloup’s GPX loader demo!

Jupyter for Geo Sciences

Jupyter’s adoption is exploding in the GeoScience space. Notable projects building upon Jupyter include

JEODPP (JRC Earth Observation Data and Processing Platform) is a EU project providing petabyte scale storage and high-throughput computing capacities to facilitate large scale analysis of Earth Observation data. The main front-end to the platform is base on Jupyter. The mapping capability is based on ipyleaflet. End users can request custom visualization that are returned to them in the form of lazily computed tile layers.
Pangeo is a community platform providing open, reproducible, and scalable sciences. The Pangeo software ecosystem involves open source tools such as xarray, Iris, Dask, Jupyter, and many other packages.
It was recently announced that the NSF would be funding the UC Berkeley + NCAR “EarthCube” proposal “Jupyter meets the Earth: Enabling discovery in geoscience through interactive computing at scale”. The plan involves the development of interactive dashboards with Voilà and contributions to the Voilà codebase.

Jupyter-gmaps

We should mention the jupyter-gmaps project by Pascal Bugnion. Jupyter-gmaps is a bridge between Google maps and Jupyter. Just like ipyleaflet, jupyter-gmaps is built upon the jupyter interactive widgets framework but relies on Google maps for the display instead of LeafletJS library.

This is a high-quality widget by another core developer of ipywidgets. Pascal is also one of the people behind Voilà and the Voilà gallery.

Folium

The Folium project enables maps visualization in the Jupyter notebook. Just like ipyleaflet, it is based on LeafletJS. Folium was created by Rob Story and is now maintained by Frank Conengmo and Filipe Fernandes.

A key difference between Folium and ipyleaflet is that ipyleaflet is built upon ipywidgets and allows bidirectional communication between the front-end and the backend enabling the use of the map to capture user input, while Folium is meant for displaying static data only. Folium enables many LeafletJS extensions, some of which may not be available in ipyleaflet at the moment.

Acknowledgements

The ipyleaflet project was started in 2015 by Brian Granger, and funded by the ERDC. The further development by Sylvain Corlay and Martin Renou was supported by QuantStack.

We are grateful to OVH for kindly hosting the Voilà gallery.

Other key contributors to Voilà and ipyleaflet that should be thanked here are Maarten Breddels, Pascal Bugnion, and Yuvi Panda. We should also mention the recent contributions by Vasavan Thirusittampalam who worked on the full-screen control and better interoperability with geopandas.

About the Authors

Sylvain Corlay, and Martin Renou are Scientific Software Developers at QuantStack.

Sylvain Corlay

Sylvain Corlay is the founder and CEO of QuantStack.

As an Open Source Developer, Sylvain contributes to Project Jupyter in the areas of interactive widgets and language kernels and is a steering committee member of the Project. Beyond QuantStack, Sylvain serves as a member of the board of directors of the NumFOCUS foundation. He also co-organizes the PyData Paris Meetup.

Martin Renou

Martin Renou is a Scientific Software Developer at QuantStack. Prior to joining QuantStack, Martin also worked as a Software developer at Enthought. He studied at the French Aerospace Engineering School ISAE-Supaero, with major in autonomous systems and programming.

As an open source developer, Martin has worked on a variety of projects, such as SciviJS (a JavaScript 3-D mesh visualization library), Xtensor, and Xeus.

A new Python kernel for Jupyter

2019-01-09T09:16:00+00:00

Project Jupyter aims at providing a consistent set of tools for interactive computing workflows across multiple programming languages. Jupyter projects are popular at all stages of a research project from the exploration phase to the communication of results and teaching.

The flagship project of Jupyter, the Notebook, and its modernized version, JupyterLab are web applications allowing the creation of documents including prose, executable code, and interactive visualizations.

The kernel is the part of the backend responsible for executing code written by the user in the web application. For example, in the case of a Python notebook, execution of the code is typically handled by ipykernel, the reference implementation.

History

Initially, the IPython project included everything from the notebook web application to the kernel and server implementation. Later on, the language-agnostic parts (the notebook format, messaging protocol, qtconsole, notebook web application) were split into separate projects with a clearer scope, together forming Project Jupyter.

The Big Split(TM) of IPython

Splitting IPython into multiple packages was a good decision in that it brought a clear separation of concerns between the projects. The ipykernel project was elected as the reference implementation of the Jupyter kernel protocol.

This came at a cost since ipykernel brought all the history and technical debt of IPython with it. Besides, Python is not a natural language for a base implementation. As a result, R and Julia kernels don’t use the reference implementation but use their own implementation of the protocol.

Furthermore, the standard implementation of the Jupyter Interactive Widgets lies in the Python package ipywidgets. That means that once you, as a kernel developer, implemented the Jupyter kernel protocol, you would still need to make your own backend for the interactive widgets if you want widgets support (and you should want it, honestly…).

To prevent this useless duplication of effort, which harms sustainability, we set ourselves to implement a solid reusable implementation of the Jupyter kernel protocol, xeus.

C++ implementation of the kernel protocol

Xeus is a C++ implementation of the Jupyter kernel protocol. It is not a kernel by itself but a library that helps kernel authoring. Xeus is very helpful when developing a kernel for a language that has a C or a C++API (Python, Lua, SQL, etc.). It takes the cumbersome task of implementing the Jupyter messaging protocol for you so you just can focus on the core interpreter tasks: executing code, inspecting, completing, etc.

C++ is a good choice for a standard implementation of the protocol, it is a common denominator of most of the languages out there, it has a massive developer community and is widely adopted in the industry for performance middleware applications.

With xeus, it is also very easy to reimplement core logic (server, kernel, history management etc.), if need be, by simply inheriting from xeus library classes.

Xeus is already known for being used as a base for the C++ kernel xeus-cling.

A xeus-based C++ Kernel

Xeus-cling is a xeus-based C++ kernel for the Jupyter Notebook. It’s very useful for teaching or learning C++. C++ has never been this interactive, thanks to the combined power of Jupyter, xeus, and cling. And even more impressive than executing interpreted C++, it supports interactive widgets, thanks to the xwidgets project.

Just like xeus is a C++ implementation of the Jupyter kernel protocol, xwidgets is a C++ implementation of the Jupyter Interactive Widgets protocol, and it can be used as a base for other implementations.

You can try it right now with binder, without the need of installing anything on your computer, just by clicking on this link.

Interactive C++ in the Jupyter Notebook

A xeus-based Python kernel

Today, I am pleased to announce a new Python kernel based on xeus: xeus-python.

Xeus-python supports error formatting, rich display, interactive widgets, input requests, code completion, code inspection, etc.

Thanks to xeus and pybind11, it was very straightforward to have a first simple version of a Python kernel written in C++. It took a couple of months to have the features listed above, with a relatively small amount of code (< 3000 lines of C++) and a good coverage of ipykernel’s features.

Simple code execution

Error formatting

Code completion

Ipywidgets support

Just like with xeus-cling, you can try it online without the need of installing anything on your computer following this link.

Why another Python kernel?

Obviously, xeus-python does not cover 100% of the features of ipykernel. For examples, IPython magics are not supported yet by xeus-python. However:

xeus-python is a lot lighter than ipykernel and IPython combined, which makes it a lot easier to implement new features on top of it. Our next goal is to augment the protocol to implement a Python debugger in JupyterLab.
xeus-based kernels are more versatile in that one can overload e.g. the concurrency model. This is something that Kitware’s SlicerJupyter project takes advantage of to integrate with the Qt event loop of their Qt-based desktop application.

Acknowledgments

The development of xeus, xwidgets, xeus-python, and related packages are led by QuantStack.

This development is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he studied at the French Aerospace Engineering School SUPAERO. He also worked at Logilab in Paris and Enthought in Cambridge. As an open source developer at QuantStack, Martin worked on a variety of projects, from xsimd, xtensor, and xframe in C++ to ipyleaflet and ipywebrtc in Python and JavaScript.

Interpreted C++ for GIS with Jupyter

2018-04-24T08:35:00+00:00

A live interactive map in a C++ Jupyter notebook

The recent release of the Jupyter kernel for C++, based on the Cling interpreter enabled a number of new workflows for the users of the C++ programming language.

Features of the xeus-cling C++ kernel for Project Jupyter include:

Showing quick-help pages for functions and classes of the STL and user-defined types, by prefixing them with a question mark:
For example, typing ?std::vector results in a pager displaying the page from cppreference on std::vector.

Quick-help page for classes and functions of the STL
Making use of the rich display features of the Jupyter stack, for user-defined types.
This can be enabled simply by overloading mime_bundle_repr in the namespace of the class for which we wish to have a rich representation in the front-end. The overload is picked up by the display system through argument-dependent lookup (ADL).

Using Jupyter’s rich display mechanism in C++
Another aspect of the newly released C++ kernel is the implementation of the Jupyter widgets protocol, enabling bi-directional communication between the front-end and the kernel. The xwidgets package, built upon xeus provides a complete implementation of the protocol, together with the implementation of most of the controls available in the reference ipywidgets Python package.

Bidirectional communication with the front-end using Jupyter interactive widgets

More than a limited set of base controls, Jupyter widgets are a framework upon which one can build arbitrarily complex interactions. A large number of interactive widget libraries has been built upon ipywidgets. Popular examples include pythreejs (a Jupyter-threejs bridge), bqplot (an interactive plotting library for Jupyter), and ipyleaflet (a Jupyter-leafletjs bridge) allowing rich interactive maps in the Jupyter notebook.

A common trait of most of these packages is that most of the logic is implemented in the front-end, while the back-end only involves synchronization of data attributes.

A fully-specified communication protocol and a thin back-end architecture facilitate the job of kernel authors willing to bring the power of these visualization libraries to their language of choice.

Hence, we have taken on the endeavor of providing a C++ implementation of the most popular Jupyter interactive widget libraries. These packages can be used in the C++ kernel, as well as in compiled application making use of the Jupyter kernel protocol.

Today, we are proud to announce the first release of xleaflet, the C++ counterpart to the popular ipyleaflet package, and which makes use of the same front-end component.

You can get started by simply creating a map inline in the Jupyter notebook.

Specifying a center location and zoom level
Specifying the tile layers to be displayed among the predefined base maps

A simple map with a specified center and zoom level, displaying the default tiles

A number of other attributes can be set in the map widget. To mimic named parameters, all widgets of xwidgets and xleaflet are provided with a generator class which can be used to initialize attributes using method-chaining syntax.

Making use of the generator class to specify any number of attributes of the map upon construction

In addition to the base map feature, a broad number of features of the leaflet JavaScript library are exposed to the C++ backend directly. This includes markers, marker clusters, image overlays, a variety of controls.

Using the marker widget

Whenever an attribute of a widget is modified in the front-end or in the back-end, the other side will properly reflect the data change.

For example, setting marker.location to a new value in the previous example will actually move the marker on the map. Reversely, if the draggable attribute was set to true, whenever the marker position changes in the front-end, the value is reflected in the C++ model.

Observer on the marker position

Another example is the support of the GeoJSON format, which allows one to load a JSON file locally and display its content on the map.

Support for the GeoJSON format

The bidirectional communication between the front-end and the C++ back-end makes it easier for the end user to create interactive web applications without having to write any JavaScript.

Using the rich features of xleaflet, one can start building fully-fledged GIS application in C++.

If you are interested in trying xleaflet right now in your web browser, we provided a binder for you.

Simply click on the following binder link and start playing with interactive GIS in C++ in your web browser:

Click on the image to launch the live demo.

Check out the documentation for more detailed information about xleaflet.

Aknowledgements

The software presented in this post was built upon the work of a large number of people including the Jupyter team, the Cling developers, the developers of xeus and xwidgets, and the developers of leafletjs.

We are especially grateful to Sylvain Corlay, Loic Gouarin, Johan Mabille, and Wolf Vollprecht.

The development of xeus, xwidgets and related packages at QuantStack is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software developer at QuantStack. Prior to joining QuantStack, Martin studied at the French Institute of Aeronautics and Space. As an open source developer, he worked on a variety of projects, notably SciviJS, a JavaScript library for 3-D mesh visualization.