Jupyter Blog - Project Jupyter

2026 Jupyter Community Call For Funding Proposals

2026-07-06T19:32:00+00:00

The Jupyter Executive Council and Jupyter Foundation are pleased to announce a new Call for Proposals (CFP) for funding the Jupyter community to improve Jupyter. Visit the Jupyter Foundation Community Proposals webpage to learn more about the process and how to submit proposals. Submit a proposal by Wednesday, September 9, 2026.

The Jupyter Foundation began its operations in early 2025 with a mission to use its resources to support the Jupyter community. As part of this mission, we funded a round of community proposals in 2025. This funded work continues to bring many benefits to the Jupyter ecosystem (see the progress reports here). In this next call for proposals, we are iterating on this success.

Visit the Community Proposals webpage to learn more about past funded proposals and the Jupyter Foundation team compass for more detailed background about this funding call. In this second round, our goal is to continue learning how to best manage a community funding program. Based on feedback, we are updating the proposal process in several ways, including:

A new section of the proposal template has been added for Jupyter council or committee endorsements. We strongly encourage authors to seek and include endorsements from Jupyter councils or committees affected by the proposal. Each endorsement should be a brief paragraph about the impact of the proposed work from the council or committee’s perspective, and express support for the work and a willingness to receive it. We encourage authors to communicate early with relevant Jupyter councils and committees to make this endorsement process easier.
The de-risk section of the proposal is now optional for smaller funding requests.
The CFP is open for several weeks longer than the previous round. We do not anticipate extending the CFP deadline this time.

Submit a proposal by Wednesday, September 9, 2026.

As with the previous round, to help inspire proposals we are particularly excited to fund, we’ve defined funding priorities for the Jupyter Foundation. These are key outcomes that we must improve in order to grow the overall health and impact of the ecosystem. Briefly summarizing, these priorities are:

Grow the contributor capacity of Jupyter. We would like to grow the number of contributors, improve the efficiency of existing contributors, and facilitate learning across Jupyter subprojects. We’d love to see proposals that help us mobilize and support the total pool of energy available to contribute to Jupyter. Examples of recent activities in this area include hiring a community manager and hosting community workshops.
Improve the reliability, security, and consistency of Jupyter’s software and team practices. We believe that our technology will be more impactful and easier to contribute to and deploy if we improve our development infrastructure and team practices in ways that contribute to reliability, security, and consistency. Examples of recent activities in this area include investing in better testing infrastructure and linting rules, refactoring build systems, improving accessibility, funding security issue triage, and hosting a subproject roadmap alignment workshop.

While we’re particularly excited about these two outcomes and aim to focus funding on proposals that clearly feed into one or both of these priorities, we also encourage people to get creative and submit proposals for outcomes that have high impact and strategic value for the Jupyter community. We’re excited to see what others come up with, and are eager to work with you in unlocking critical funding in support of Jupyter’s community.

JupyterLite Officially Joins Project Jupyter!

2026-02-12T16:14:00+00:00

We are thrilled to announce that JupyterLite is now an official part of Project Jupyter. This milestone marks a significant step forward for interactive computing in the browser and strengthens JupyterLite’s role within the Jupyter ecosystem.

What is JupyterLite?

JupyterLite is a JupyterLab distribution that runs entirely in your web browser. Kernels execute directly in the browser using WebAssembly, eliminating the need for an application server. This means:

Instant access: Start computing with a single click: no prior Python setup, environment configuration, or server management required.
Scalability: Host thousands of concurrent users from a static website (e.g., GitHub Pages) with zero per-user server costs.
Privacy and portability: Code and data remain in the user’s browser, making it ideal for embedding in documentation, tutorials, and interactive demos.

JupyterLite greatly expands the options available in the Jupyter ecosystem for education, documentation, and demos, where reducing friction is critical.

As Brian Granger reminded us during his JupyterCon 2025 keynote, Jupyter’s mission is “to empower people of all backgrounds to think, collaborate, and share knowledge using computational storytelling.” From this perspective, JupyterLite is a logical and key next step to take, letting Jupyter take advantage of the impressive strides made in recent years by the WebAssembly/JavaScript ecosystem (in reach and capability) to advance this mission. JupyterLite is an excellent complement to other forms of accessing Jupyter (whether through a local Python installation or a hosted infrastructure service), that facilitates new use cases and lowers barriers in many others.

Interactive computing in the browser with JupyterLite

The Journey of JupyterLite

JupyterLite’s development began in 2021, led by Jeremy Tuloup at QuantStack. Over the past four years, it has benefited from the dedication of several other team members, Martin Renou, Trung Le, and Ian Thomas — as well as invaluable contributions from community members like Nick Bollweg and many others.

Beyond the JupyterLite repository, the project includes comprehensive tooling for creating in-browser language kernels based on xeus. These kernels support languages like Python, R, C++, GNU Octave, Lua, and SQLite, sharing the same codebase as their backend counterparts, developed by Thorsten Beier, Isabel Paredes, Johan Mabille, and Antoine Prouvost. These kernels are built upon the emscripten-forge software distribution for WebAssembly. The project also includes a Python kernel based on Pyodide, and kernels for JavaScript and p5.js. This architecture means that the same language-agnostic model for kernels that Jupyter pioneered over a decade ago, carries over to the WebAssembly world.

The JupyterLite GitHub organization also features the JupyterLite Terminal, a terminal and shell emulator that runs entirely in the browser and was developed by Ian Thomas. It enables the use of basic Unix commands like grep, sed, cat, touch, and even vim or nano, all built to WebAssembly.

The JupyterLite terminal emulator, with basic Unix commands

JupyterLite now powers the official Jupyter website and is used by projects like numpy.org, sympy.org. It also underlies services such as Jupyter Everywhere and notebook.link.

A Natural Fit with JupyterLab

JupyterLite has always been closely tied to JupyterLab. It is increasingly becoming a set of JupyterLab extensions that replace core plugins to manage kernels, settings, and content in the browser. With contributors overlapping significantly with the Jupyter Frontends group, this integration formalizes what many in the community already recognized: JupyterLite is a core part of the Jupyter ecosystem.

The proposal to transfer JupyterLite to the Jupyter governance received strong support from the Jupyter community and by the Jupyter Frontends council.

Better integration with the rest of Jupyter

With JupyterLite now being an official part of Jupyter, it will be easier to find areas for better integration with other aspects of our ecosystem: we can reduce duplication, smooth out the documentation and model for creating and using both “traditional” (server-hosted) and WebAssembly kernels, and make JupyterLite a natural instant-access component of MyST/JupyterBook-based sites, and more.

Mission-wise, JupyterLite is a natural next step for Jupyter, and having it be an official part of the project makes it much easier for the community to integrate its benefits throughout. We hope you’ll try it, use it and contribute to its growth!

Try it in your browser

If you would like to try JupyterLite in your browser, click on the following link:

Acknowledgments and team credits

JupyterLite’s success is thanks to the support of individuals and organizations who believed in its vision. This includes:

QuantStack, for their continued investment in the project since 2021 and the broader Jupyter ecosystem,
Bloomberg, for funding improvements to JupyterLite by QuantStack since 2023,
The Gates Foundation, for funding the development of the xeus-R kernel and its port to WebAssembly,
The Pyodide project, whose pioneering work on Python in the browser via WebAssembly made JupyterLite possible.

Key developers to this stack include:

Jeremy Tuloup (Director at QuantStack, creator of JupyterLite, and JupyterLab maintainer),
Nicholas Bollweg (JupyterLite maintainer and #2 all-time committer),
Martin Renou (Director at QuantStack, JupyterLite maintainer, responsible for integrating xeus with emscripten-forge, and creator of JupyterLite-Sphinx),
Thorsten Beier (Software developer at QuantStack, lead developer of emscripten-forge, and xeus-lite),
Isabel Paredes (Software developer at QuantStack, led the packaging of R and GNU Octave in Emscripten-forge),
Anutosh Bhat (Software developer at QuantStack, C++ kernel in the browser),
Ian Thomas (Software developer at QuantStack, creator of the JupyterLite terminal, and the cockle shell emulator),
Johan Mabille (Director at QuantStack, creator of xeus),
Agriya Khetarpal (Pyodide contributor, JupyterLite-Sphinx maintainer),
Albert Steppi (JupyterLite-Sphinx maintainer).

Thank you for being part of this journey, we cannot wait to see what you build with JupyterLite!

— this post was coauthored by Jérémy Tuloup, Sylvain Corlay, and Fernando Pérez

Project Jupyter’s 2025 Executive Council Elections

2025-03-06T16:26:00+00:00

Project Jupyter recently completed its 2025 Executive Council (EC) election, marking an important transition in its leadership. The newly elected members — Afshin Darian, Chris Holdgraf, and Rick Wagner — will serve two-year terms, helping guide strategic and operational direction for Project Jupyter.

Rick Wagner, San Diego Supercomputer Center (2025–2027)
Afshin Darian, QuantStack (2025–2027)
Chris Holdgraf, 2i2c (2025–2027)
Ana Ruvalcaba, Cal Poly State University San Luis Obispo (2024–2026)
Jason Grout, Databricks (2024–2026)
Zach Sailer, Apple (2024–2026)

Who Are the Newly Elected EC Members?

The three elected members bring deep expertise and long-standing contributions to Jupyter:

Afshin Darian was part of the inaugural Executive Council in 2023 and is continuing in his role as an EC member. He has contributed to Jupyter’s transition to the Linux Foundation, alongside his work on the architecture of Jupyter and accessibility.
Chris Holdgraf has played a key role in JupyterHub, Binder, and Jupyter Book, helping to sustain and grow these vital subprojects. He is also the executive director of a non-profit called 2i2c that manages JupyterHub infrastructure for communities in research and education.
Rick Wagner has been active in Jupyter’s Security Subproject, advocating for secure development practices and leading major security initiatives.

Their collective experience spans technical innovation, community governance, security, and sustainability, ensuring that Jupyter continues to evolve in a way that serves users, contributors, and the broader ecosystem. Darian, Chris, and Rick will join the members serving in their current two-year terms, Jason Grout, Ana Ruvalcaba, and Zach Sailer. Together, the EC members represent industry, academic, and non-profit organizations.

Creating Open, Sustainable, Leadership

When Jupyter was created, it followed a “Benevolent Dictator for Life” (BDFL) style of governance that was popular in open source communities at the time. Throughout the 2010s, the project learned (along with many others in the open source ecosystem) that BDFL models for complex projects are not sustainable for both the project and for its contributors. As a result Jupyter began a long-term initiative to move away from its BDFL decision-making structure. It began by adopting a Steering Council model, where a group of peers made consensus-based decisions across the entire project. This distributed Jupyter’s decision-making authority, but did not efficiently represent the breadth and complexity of Jupyter’s ecosystem.

In 2022, Project Jupyter took the next step towards formalizing and decentralizing its governance. It adopted a more dynamic, distributed, and community-driven structure. Jupyter’s governance model guides the development of over a dozen distinct software components and several groups focused on specific activities, including accessibility and security. Software design and development is handled by individual Subprojects, with each Subproject typically responsible for one or more software components or packages. Subprojects elect representatives to the Software Steering Council which has jurisdiction over software-related decisions across Project Jupyter. The Executive Council is chosen via elections and has the ultimate responsibility for all aspects of Project Jupyter, including its software, finances, trademark, operations, etc. In 2024, this extended to the creation of the Jupyter Foundation, a directed fund of the Linux Foundation 501(c)(6) whose purpose is to raise, budget and spend funds in support of Project Jupyter and its mission. The Foundation Governing Board controls the resources of the Foundation, and works to build a healthy collaboration between the Jupyter community, Jupyter leadership, and members of the Jupyter Foundation.

Jupyter recently completed its 2025 election for the Executive Council. This election is especially significant because it marks the first time that Fernando Pérez and Brian Granger, two of Jupyter’s founding figures, will not serve in the executive leadership body of the project. Their voluntary departure from the EC reflects their confidence in the governance model established in 2022 and is an indication that the new model is progressing toward its goal: creating a self-sustaining leadership structure where contributors from across the Jupyter ecosystem can contribute their talents. Going forward, Brian will continue to be involved in Jupyter’s software and will serve on the Governing Board of the Jupyter Foundation. Fernando will remain actively involved with various parts of the Jupyter ecosystem, including JupyterHealth, MyST, Jupyter uses in science and education through 2i2c, Jupyter-AI, and the nascent GeoJupyter (independent) community effort.

What This Means for Jupyter’s Future

The success of this election signals a healthy, evolving open-source project, where leadership is dynamic, inclusive, and community-driven. It shows that Jupyter’s governance changes have not only ensured continuity but have also empowered new voices to take on leadership roles to serve the community.

The departure of Fernando and Brian from official leadership positions is not an end, but a milestone — a testament to our vision for an open, thriving, and community-led project.

The Jupyter community now looks ahead to the next era of innovation, collaboration, and sustainability with support from all of its contributors.

Project Jupyter joins LF Charities

2024-10-23T19:00:00+00:00

We are excited to announce that Project Jupyter is entering a new phase in our journey: we are joining LF Charities, a 501(c)(3) non-profit under the Linux Foundation. See the official press release from Linux Foundation and the blog post from NumFOCUS.

In the last decade, Jupyter has grown tremendously. From our roots as an evolution of the IPython project, Project Jupyter is now the de facto standard for interactive computation in data science, scientific computing, and machine learning. The software and standards developed by the Jupyter community span a rich and diverse ecosystem that includes data science, geospatial data analysis, physics, chemistry, CAD, and many other areas.

In order to sustain this momentum, continue innovating in the space of interactive computational tools for thinking and collaborating, and better serve our community, we are introducing the new Jupyter Foundation, a vehicle for the project to formally engage with industry partners and other organizations. We invite organizations of all types, including companies, government agencies, and non-profits who support our mission to join us through the Jupyter Foundation. For information on joining, please see https://jupyterfoundation.org.

As background for this change, the Project Jupyter Executive Council began exploring options for the next phase of our growth over a year ago. In March 2024, we presented a high-level proposal to the community for Jupyter to transition to LF Charities as its legal home. An open discussion was hosted on GitHub for the community to discuss this idea, generating a lot of feedback, which was incorporated into the main proposal document. Once discussion settled, on June 14, 2024, we moved to a formal vote as per our governance model, in which the Jupyter Executive Council and the Jupyter Software Steering Council jointly approved moving forward with the transition to the LF Charities. We have since then worked with both NumFOCUS and Linux Foundation leadership to formalize the transition, which is completed today. We sincerely thank NumFOCUS for their support of IPython and Jupyter, and we look forward to continuing collaborating with the entire community of NumFOCUS projects.

If you are a user or supporter of Jupyter in any capacity, please help us spread the word about this new phase for the project, and encourage organizations to support our mission through the Jupyter Foundation.

JupyterLab 4.1 and Notebook 7.1 are here 🎉

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

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

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

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

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

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

Custom CSS

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

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

Diagrams in Markdown

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

```mermaid
flowchart LR

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

which renders as:

Inline code completion

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

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

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

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

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

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

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

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

Execution history in notebook

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

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

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

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

Opening files from tracebacks

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

Error indicator in the table of contents

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

Plugin Manager

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

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

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

Virtual scrollbar for notebook in windowed mode

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

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

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

Notifications

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

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

Full notebook windowing mode improvements

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

Search improvements

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

Acknowledgements

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

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

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

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

and everyone who tested the pre-releases!

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

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

JupyterLab 3 end of maintenance

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

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

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

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

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

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

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

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

Jupyter Media Strategy & Social Media Update

2024-01-10T21:00:00+00:00

Project Jupyter is on Hachyderm

Summary of announcement

We are excited to announce the formation of the Jupyter Media Strategy working group (JMS)!

The growth of the Jupyter community has led to an increase in the number of people who want to engage with our brand and an increase in the number of official Jupyter media channels. As the use of our public channels has grown, it is clear we need to have a better structure for managing not only access to the various accounts but also a more cohesive strategy for the messaging presented on those channels.

The JMS will ensure communications in Jupyter official channels are strategic and benefit Project Jupyter. Jupyter publications, social media posts, promotions and other media activity are meant to be community driven, as supported by distributed responsibilities in the Jupyter governance model. The JMS will enable access for the community to speak publicly through the official Jupyter communication channels. The JMS will also help to improve Jupyter media activity by creating strategy and guidelines, serving as editors for existing public media channels, and overseeing creation/delegation of new media channels.

If you have a Jupyter or Open Source related message or story that you would like to share within the Jupyter official channels, here is a checklist to guide you.

Please plan ahead. We are primarily a group of volunteers and we will review requests on a weekly basis.
Submit your post to Jupyter publication. Follow submission guidelines and processes outlined here.

The JMS will respond to your request. Possible outcomes include:

Approval: the JMS will publish your blog post taking into account other pending posts in the editorial lineup as need be.
Request for revision of content: guidance for improvements.
Rejection of topic: we’ll share reasons why we’re unable to publish your topic.

Jupyter Official Channels

Mastodon is currently Project Jupyter’s preferred social media channel. Other social media channels may be used to amplify posts from the Project Jupyter blog.

Discourse: https://discourse.jupyter.org
LinkedIn:https://linkedin.com/company/project-jupyter
Medium: https://blog.jupyter.org
Mastodon:https://hachyderm.io/@ProjectJupyter
Slack JupyterLab: https://jupyterlabworkspace.slack.com
X/Twitter:https://twitter.com/ProjectJupyter
YouTube:https://youtube.com/@ipython

Meet the JMS

Ana Ruvalcaba (top left), is a Director at California Polytechnic University, San Luis Obispo. She serves on the Jupyter Executive Council and various community groups at Jupyter including DEI and Community Building.

Andrii Ieroshenko (top right) is a Software Development Engineer at AWS. Andrii is a Project Jupyter contributor and community member. He serves on the JupyterLab and Jupyter Notebook councils.

Steven Silvester (bottom left), is an Engineering Lead at MongoDB. He serves on the Jupyter Executive Council and a member of several software steering councils.

Jake Diamond-Reivich (bottom right), is a Founder at Mito. He serves on Jupyter Media Strategy Working Group. Jake is excited to help Jupyter flourish by optimizing community communications and making it easier for people to engage with the community.

Send us your feedback

If you have general questions or ideas related to Jupyter Media Strategy we welcome feedback. Contact the JMS at jupyter-media-strategy@googlegroups.com.

Recent keyboard navigation improvements in Jupyter

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

Towards a more accessible Jupyter Notebook

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

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

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

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

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

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

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

Notebook Tab Traps

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

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

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

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

Future accessibility improvements

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

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

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

Feedback

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

About the Authors

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

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

Acknowledgments

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

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

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

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

Announcing Jupyter Notebook 7

2023-07-26T16:08:00+00:00

Jupyter Notebook 7 is the most significant release of the Jupyter Notebook in years. Some highlights of this release include real-time collaboration, interactive debugging, table of contents, theming and dark mode, internationalization, improved accessibility, compact view on mobile devices.

Both Jupyter Notebook and JupyterLab are widely used across data science, machine learning, computational research, and education. With the release of JupyterLab 4 and Jupyter Notebook 7, the two sibling applications offer a unified, flexible, and integrated experience that allows you to get the best of both, in whatever combination that makes sense for you.

Jupyter Notebook 7 with a running Python 3 notebook

Since Notebook 7 is based on JupyterLab, it includes many of the new features and improvements that have been added to JupyterLab over the past few years.

Here is a small glimpse of what users can expect when they upgrade from Jupyter Notebook version 6 to version 7.

A Familiar Document-Oriented Experience

Starting with what does not change, Notebook 7 still focuses on the document-centric user experience that made the classic IPython and Jupyter Notebook application so popular.

It keeps the clean and lean interface that users love, and it enables you to create and edit the same Jupyter notebook .ipynb files that contain live code, equations, visualizations and narrative text.

Visual Debugger

Notebook 7 includes the interactive debugger from JupyterLab, which enables you to step through your code cell by cell. You can also set breakpoints and inspect variables.

Visual debugging in Jupyter Notebook 7

Real-Time Collaboration

Notebook 7 enables you to use the same real-time collaboration extension as JupyterLab so you can share your notebook with other users and edit it in real time. This even works across JupyterLab and Jupyter Notebook! To start using real-time collaboration, you will need to install the jupyter-collaboration extension:

pip install jupyter-collaboration

A side-by-side animated example of real-time collaboration in Jupyter Notebook 7

Theming and Dark Mode

A dark theme is now available in the Jupyter Notebook by default.

Jupyter Notebook 7 with JupyterLab Dark theme

You can also install many other JupyterLab themes. For example to install the JupyterLab night theme:

pip install jupyterlab-night

Jupyter Notebook 7 with JupyterLab Night theme

Improved integration between JupyterLab and Notebook

We have built Notebook 7 and JupyterLab 4 to work well together. When you run either application using jupyter lab or jupyter notebook, we automatically detect if the other application is installed and enable its user experience as well. This is possible as both JupyterLab and Notebook use the same underlying server and extension system. From a user experience perspective, this allows you to easily open a notebook in the other application using the “JupyterLab” and “Notebook” buttons as the top of each notebook. This makes it seamless to move back and forth between the two applications to best match your work.

More features

You can find a list of the new features in the Jupyter Notebook documentation.

Why a new version?

Following feedback from the community, we decided in late 2021 to continue developing the Jupyter Notebook application and sunrise it as Notebook 7.

The major change is building the Jupyter Notebook 7 interface with JupyterLab components so that the two applications share a common codebase and extension system. We have worked hard to ensure that the experience users know and love from Jupyter Notebook 6 is preserved, even as we have added many new features to Notebook 7. Let’s dive into those new features!

You can find more details about the rationale behind this new release in Jupyter Enhancement Proposal 79.

Migrating to Notebook 7

The Jupyter Notebook Team has been working to make the transition from Notebook 6 to Notebook 7 as smooth as possible. The Notebook 7 release is a good opportunity to try out the new features and report any issues you may encounter.

Because the architecture of Notebook 7 is rebuilt from the ground up, we recognize that some existing users might need a medium-term option for backward-compatibility with Notebook 6 using NbClassic, which delivers the same user experience and can be run on the same server as JupyterLab and Notebook 7. This means that the server hosting your Notebook can deliver those 3 difference user interfaces at the same time.

There is also a migration guide to help you upgrade to the new version.

Try it on Binder

You can try Notebook 7 on Binder using this link.

Acknowledgements

The work on Notebook 7 by Jeremy Tuloup was supported by QuantStack.

Anaconda supported work on Notebook 6 and 7, NbClassic, documentation and maintenance.

Get Involved

There are many ways you can participate in the Notebook 7 effort. We welcome contributions from all members of the Jupyter community:

Make your own extensions. You can also help the community by porting Classic Notebook extensions to Notebook 7.
Contribute to the development, documentation, and design of Jupyter Notebook on GitHub. To get started with development, please see the Contributing Guide and Code of Conduct. Many issues are ideal for new contributors and are tagged as “good first issue” or “help wanted”.
Connect with the community on GitHub or on Discourse. If you find a bug, have questions, or want to provide feedback, please join the conversation!

🎉 JupyterCon 2023 recordings now live on YouTube! 🎉

2023-07-22T21:14:00+00:00

Get ready to relive the magic of JupyterCon 2023, because the long-awaited moment is finally here! The JupyterCon YouTube channel has just dropped a treasure trove of content — all the talk and keynote recordings from the most epic conference of the year.

Held at the Cité des Sciences in the city of Paris, from May 10 to 12, JupyterCon 2023 was a celebration of all things Jupyter and beyond.

You can now access all the knowledge-packed sessions online. Don’t miss this opportunity to be inspired by visionaries and experts from different fields who shared their insights on the future of Jupyter.

We extend our heartfelt gratitude to the sponsors, speakers, attendees, and volunteers who contributed to the vibrant atmosphere and made JupyterCon 2023 a memorable experience. Together, we’ve created a platform for knowledge sharing, innovation, and collaboration, empowering data scientists, researchers, educators, and developers worldwide. Thank you for making this conference possible!

On behalf of the JupyterCon 2023 organization committee,

Gayle Ollington — Jupyter Community Events Manager
Sylvain Corlay — JupyterCon 2023 General Chair

Jupyter Community 2021 Update

2021-12-20T17:53:00+00:00

Attendees to the June 2019 Community Workshop on Dashboarding in Paris (Photo credit to Lindsey Heagy)

New committee announcement

Project Jupyter is happy to share some exciting news in key efforts to connect the global Jupyter community. First, we’d like to introduce a new committee that was created to act on behalf of the Project Jupyter Steering Council with the objective of growing, building, and connecting the global Jupyter community of users and contributors. You can learn more about the Jupyter Community Building committee here.

We’re hiring!

We are hiring a Jupyter Community Events Manager to help manage Jupyter Community Workshops and the JupyterCon conference. Check out the blog post about the position at NumFOCUS blog.

Jupyter Community Workshops

The Jupyter Community Workshop program has been an outstanding success in bringing together small groups of Jupyter community members and core contributors for high-impact strategic work and community engagement on focused topics. Community members have hosted 11 community workshops since 2018 exploring using Jupyter in specific disciplines (education, scientific facilities with supercomputers), promoting Jupyter around the world (Hawaii, South America, D.R. Congo), and developing core Jupyter projects and attracting new contributors (Jupyter server, Jupyter widgets, Jupyter kernels, nbgrader, Voilà).

Many more workshops were in planning stages when the COVID-19 pandemic abruptly paused in-person gatherings globally in March, 2020. All workshops were put on hold until 2021, and organizers are currently working through how to best proceed in the still-uncertain environment around global in-person gatherings (for example, scheduling far into the future, or moving to a virtual gathering). Two upcoming workshops have been scheduled for 2022 (on accessibility in Jupyter and Jupyter in musculoskeletal research), and more workshops are in the planning stages. Stay tuned for more details.

JupyterCon

In 2017 and 2018, our first two global user conferences were made possible through a grant from the Leona M and Harry B Helmsley Charitable Trust and a partnership with O’Reilly Media and NumFOCUS.

Unlike in 2017 and 2018, JupyterCon 2020 was entirely led by the community. Together with NumFOCUS, a team of community volunteers made the event possible, despite the enormous challenges from the COVID-19 pandemic. With over 170 tutorials, talks, and posters, and over 700 attendees, JupyterCon 2020 was a huge success. We are incredibly grateful to all the volunteers who worked on the conference and to all the participants for their contributions.

Acknowledgements

Many thanks to our generous sponsors! These community building efforts, including the hiring of an Event Manager, is made possible through significant donations from our partners at Bloomberg and AWS.

About the Authors

This post was written by the Jupyter Community Building Committee, currently composed of Ana Ruvalcaba, Jason Grout, and Sylvain Corlay.

Community Note

2021-09-08T19:40:00+00:00

We would like to acknowledge that it has recently come to our attention that a Jupyter event that took place in late Summer 2021 did not follow the agreed-upon COVID safety guidelines. The safety of our community is one of our highest priorities at Jupyter events and the Jupyter Community Building Committee on behalf of the Steering Council apologizes for any undue risk event attendees may have faced. While we understand no one fell ill from the event, this is not in line with our standards and we will make every effort to do better in the future.

A visual debugger for Jupyter

2020-03-25T15:53:00+00:00

Most of the progress made in software projects comes from incrementalism. The ability to quickly see the outcome of an execution and iterate has been one of the main reasons for the success of Jupyter, especially in scientific exploratory workflows.

Jupyter users like to experiment in the notebook, and to use the notebook as an interactive communication tool. However, for more classical software development tasks such as the refactoring of a large codebase, they often switch to general-purpose IDEs.

The JupyterLab environment.

The Jupyter project has made strides in the past few years towards filling that gap, notably with the JupyterLab project, which enables a richer UI including a file browser, text editors, consoles, notebooks, and a rich layout system.

However, a missing piece (which has remained one of the main reasons for users to switch to a different tool) is a visual debugger. This feature has long been requested by users, especially those accustomed to general-purpose development environments.

A debugger for Jupyter

Today, after several months of development, we are glad to announce the first public release of the Jupyter visual debugger!

This is just the first release, but we can already set breakpoints in notebook cells and source files, inspect variables, navigate the call stack and more.

Screencast of the JupyterLab visual debugger in action

Try the debugger on binder

You can also try the debugger online with binder. Just click on the binder link:

Click on the binder link to launch the demo

Installation

The debugger front-end can be installed as a JupyterLab extension.

jupyter labextension install @jupyterlab/debugger

The debugger front-end will be included in JupyterLab by default in a future release.

In the back-end, a kernel implementing the Jupyter Debug Protocol (which will be detailed in the next section) is required. The only kernel implementing this protocol, for now, is xeus-python a new Jupyter kernel for the Python programming language. (Support for the debugger protocol in ipykernel is also on the roadmap).

conda install xeus-python -c conda-forge

Once xeus-python and the debugger extension are installed, you should be all set to use the Jupyter visual debugger!

Note: Depending on the platform, PyPI wheels are available for xeus-python, but they are still experimental.

The Jupyter Debug Protocol

New message types for the Control and IOPub channels

Jupyter kernels (the part of the infrastructure that executes the user’s code) communicate with the rest of the infrastructure with a well-specified inter-process communication protocol.

Several communication channels exist, such as

the Shell channel, which is a request/reply channel for e.g. execution requests
the IOPub channel, which is a one-directional communication channel from the kernel to the client, and is used e.g. to forward the content of the standard output streams (stdout and stderr).

The Control channel is similar to Shell but operates on a separate socket so that messages are not queued behind execution requests, and have a higher priority. Control was already used for Interrupt and Shutdown requests, and we decided to use the same channel for the commands sent to the debugger.

Two message types were added to the protocol:

the debug_[request/reply] to request specific actions to be performed by the debugger such as adding a breakpoint or stepping into a code, which is sent to the Control channel.
the debug_event uni-directional message used by debugging kernels to send debugging events to the front-end. Debug events are sent over the IOPub channel.

Extending the Debug Adapter Protocol

A key principle to the Jupyter design is the agnosticism to the programming language. It is important for the Jupyter debug protocol to be adaptable to other kernel implementations.

A popular standard for debugging is Microsoft’s “Debug Adapter Protocol” (DAP) which is a JSON-based protocol underlying the debugger of Visual Studio Code and for which there already exist multiple language back-ends.

It was therefore natural for us to use the DAP messages over the debug_[request/reply] and debug_event messages that we just added.

However, it was not quite sufficient in the case of Jupyter. Indeed

In order to support page reloading, or a client connecting at a later stage, Jupyter kernels must store the state of the debugger (breakpoints, whether the debugger is currently stopped). The front-end can request that state over with a debug_request message.
In order to support the debugging of notebook cells and of Jupyter consoles, which are not based on source files, we also needed messages to submit code to the debugger to which breakpoints can be added.

Besides these two differences, the content of the debug requests and replies corresponds to the debug adapter protocol.

All these extensions to the Jupyter kernel protocol have been proposed for inclusion in the official specification. The JEP (Jupyter Enhancement Proposal) can be found here.

Xeus-python, the first Jupyter Kernel to support debugging

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 useful when developing a kernel for a language that has a C or a C++API (like Python, Lua, or SQL). It takes the cumbersome task of implementing the Jupyter messaging protocol for the kernel author to focus on the core interpreter tasks: executing code, inspecting, etc.

Several kernels have been developed with xeus, including the popular xeus-cling kernel for the C++ programming language, based on the cling C++ interpreter from CERN. The xeus-python kernel is an alternative Python kernel to ipykernel, based on xeus. The first release of the xeus-python kernel was announced on this blog earlier this year: https://blog.jupyter.org/a-new-python-kernel-for-jupyter-fcdf211e30a8

Xeus-python was an appropriate choice for this first implementation of the debugging protocol because

it has a pluggable concurrency model, which allowed running the processing of the Control channel in a different thread.
it has a lighter-weight codebase which made it a convenient sandbox to iterate upon. Implementing the first version of the protocol in ipykernel would have required more significant refactoring and consensus building at an early stage.

The roadmap of Xeus-python

The short-term roadmap for xeus-python includes

adding support for IPython magics in xeus-python, which is the main missing feature with respect to ipykernel.
improving the PyPI wheels of xeus-python.

What about other kernels?

The work in the front-end is valid for any kernel implementing the extended kernel protocol.

We will be working in 2020 to enable debugging with as many kernels as possible.

This will soon be the case for other xeus-based kernels which share a large part of the implementation with xeus-python, such as xeus-cling.

Diving into the debugger front-end architecture

The debugger extension for JupyterLab provides what users would typically expect from an IDE:

a sidebar with a variable explorer, a list of breakpoints, a source preview and the possibility to navigate the call stack
the ability to set breakpoints directly next to the code, namely in code cells and code consoles
visual markers to indicate where the current execution has stopped

When working with Jupyter notebooks, the state of the execution is kept in the kernel. But a cell can be executed and then deleted from the notebook. What should happen when a user wants to step in deleted code?

The extension supports that particular use case and enables retrieving a read-only view of the previously executed cell.

Stepping into a deleted cell

Consoles and files also have support for debugging.

Debugging code consoles in JupyterLab

Debugging files in JupyterLab

Debugging can be enabled on a notebook level, which lets users debug a notebook and work on a different one at the same time.

Debugging multiple notebooks simultaneously

Variables can be inspected using a tree viewer and a table viewer:

The variable explorer

The debugger extension for JupyterLab has been designed to work with any kernel that supports debugging.

By relying on the Debug Adapter Protocol, the debugger extension abstracts away language-specific features and provides a consistent debugging interface to the user.

The following diagram shows how the debug messages flow between the user, the JupyterLab extension and the kernel during a debugging session.

Using the Debug Adapter Protocol in the debugger extension (source)

Future developments

In 2020, we plan on making major improvements to the debugger experience:

Support for rich mime type rendering in the variable explorer.
Support for conditional breakpoints in the UI.
General improvements of the debugger user experience.
Enable the debugging of Voilà dashboards, from the JupyterLab Voilà preview extension.

Acknowledgements

The JupyterLab debugger is the result of the collaboration and coordination of developers from several institutions, including QuantStack, Two Sigma, and Bloomberg.

The work on both the front-end and the back-end at QuantStack by Jeremy Tuloup, Johan Mabille, Martin Renou, and Sylvain Corlay, was funded by Bloomberg.
The work on the Jupyter debugger by Borys Palka and Afshin Darian was made possible by Two Sigma.

About the developers

Jeremy Tuloup

Jeremy Tuloup is a Scientific Software developer at QuantStack. He authored a large part of the front-end of the JupyterLab debugger.
.
.
.

Borys Palka

Borys Palka is a software developer at Codete. He authored a large part of the front-end of the JupyterLab debugger.
.
.
.

Johan Mabille

Johan Mabille is a scientific software developer at QuantStack. Johan is a co-author of xeus, and developed the debugger extension to xeus-python. He also authored a large part of the debugger front-end.
.

Martin Renou

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.

Afshin Darian

Afshin Darian is a software developer at Two Sigma, and one of the authors of JupyterLab.
.
.
.
.

Sylvain Corlay

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

Jupyter Community Workshops 2019 Year in Review

2020-02-24T20:03:00+00:00

Top Image: Jupyter for Scientific User Facilities and High-Performance Computing, (Photo Credit, Fernando Perez). Bottom Left Image: Intro to Python for Kids, Parents & Teachers Workshop Series. Bottom Middle Image: Dashboarding in the Jupyter Ecosystem Workshop (Photo Credit, Lindsey Heagy) Bottom Right Image: South America Jupyter Community Workshop

2019 was a busy, successful and exciting time for Jupyter Community Workshops! Led by community members, this global event series brought together small groups of people in order to strengthen the Jupyter community and for high-impact strategic work on focused topics.

Thank you to all those in our community who made these workshops a success. It’s important to recognize the organizers who proposed, planned, and led the workshops, as well as those that supported their efforts and those that attended the gatherings. It is truly inspiring to see everyone come together to strengthen our community and to make the future of Jupyter brighter and more connected.

Our third call for proposals was announced in November of 2019. We’re happy to share that planning efforts are already under way! Stay tuned to this blog for an announcement of the Jupyter Community Workshops to be hosted in the first round of 2020.

Jupyter Community Workshops 2019

Many thanks to all those who led a workshop in 2019 (listed here in chronological order):

Jupyter Server Design and Roadmap Workshop: (Luciano Resende)
Building upon the Jupyter Kernel Protocol (Sylvain Corlay)
Jupyter nbgrader Hackathon/Code Sprint: (James Slack)
Intro to Python for Kids, Parents & Teachers Series: (Tariq Rashad)
Dashboarding in the Jupyter Ecosystem: (Pascal Bugnion, Sylvain Corlay)
Jupyter for Scientific User Facilities and High-Performance Computing: (Rollin Thomas)
South America Jupyter Community Workshop: (Damian Avila)

A special thanks to the financial sponsors of this event series, Bloomberg and Amazon Web Services. If your organization would like to support this program in the future, please contact NumFOCUS.

Jupyter Community Workshops are managed by Jupyter and NumFOCUS contributors: Ana Ruvalcaba, Jason Grout and Walker Chabbott.

Building Upon the Jupyter Protocol Workshop

The Future of JupyterCon, 2019 and Beyond

2018-12-12T18:20:00+00:00

Project Jupyter’s goals for our annual conference include serving our global community, connecting Jupyter users from different disciplines, showcasing their knowledge, and celebrating the many ways that Jupyter is making an impact in the world. In partnership with O’Reilly and NumFOCUS, with the support of many sponsors, we brought our community together for two successful Jupyter conferences, JupyterCon 2017 and JupyterCon 2018, where hundreds gathered for talks, tutorials, and code sprints. Additionally, over a hundred talks were recorded for the wider community to watch (2017, 2018).

We would like to thank the team at O’Reilly Media for partnering with us to offer JupyterCon 2017 and 2018. Their expertise in creating and managing complex events with hundreds of attendees was invaluable, and we learned a great deal from working with them.

To better serve our rapidly-growing global community and their evolving needs, Project Jupyter is re-evaluating the focus and strategic direction of future Jupyter conferences. To do so, we are organizing a diverse committee of community members who will investigate different conference formats, including a lower-cost one, and explore new venues / locations. This committee will share their results with the Jupyter Steering Council, who will decide based on these recommendations whether to host the next Jupyter conference in 2019 or defer until 2020.

If you would like to volunteer to help with the exploratory committee, please fill out the introduction form by December 21.

The previously announced dates and location for JupyterCon 2019 in August 2019 will no longer apply. We, Project Jupyter, are sorry for any inconvenience this may cause you, and we will work to keep you informed of the committee’s results and future conference plans.

In addition to the annual conference being explored by this committee, Jupyter has many other local gatherings which will continue to proceed, such as Jupyter Days, Jupyter Community Workshops, and local code sprints and open studios (read the latest event news on our blog).

As with all things Jupyter, your input is welcome on our public channels (mailing list and our experimental discourse instance). If you have a specific question that requires a private response, please contact jupyterops@gmail.com.

As we reflect on what Jupyter and its community achieved in 2018, we are humbled by your talent and impact on the world. We wish everyone a healthy and prosperous new year.

Jupyter Community Workshops

2018-07-11T18:46:00+00:00

Bloomberg is a long-time partner and supporter of Project Jupyter. Earlier this year Bloomberg announced funding of $120,000 to enable Project Jupyter to host a series of Jupyter Workshops in 2018. These workshops will bring together small groups, approximately 12 to 24 people,) of Jupyter community members and core contributors for high-impact strategic work and community engagement on focused topics.

Much of Jupyter’s work is accomplished through remote, online collaboration; yet, over the years, we have found deep value in focused in-person work over a few days. These in-person events are particularly useful for tackling challenging development and design projects, growing the community of contributors, and strengthening collaborations.

We are now soliciting proposals for Jupyter Workshops for 2018. We are particularly interested in workshops that explore and address topics of strategic importance for the future of Jupyter. We expect the workshops to involve 1–2 dozen participants over a 2–3 day period, and have a total Jupyter-funded budget of approximately $10,000 to $20,000, which may help cover expenses such as travel, lodging, meals, or event space. It is our intent for the workshops to include both participants who are core Jupyter contributors, as well as stakeholders and contributors and potential contributors within the larger Jupyter ecosystem. While not the primary focus of the workshops, it would be highly beneficial to couple the workshop with broader community outreach events, such as sprints, talks, or tutorials, at local meetings or conferences.

An excellent example of a successful, sponsored workshop is the Jupyter Widgets Workshop organized by Sylvain Corlay in February 2018. This workshop brought together the core developers of Jupyter Widgets and JupyterLab, community members developing libraries on top of widgets and JupyterLab, and new collaborators wanting to learn how to contribute to development, design, and documentation. After the workshop, a participant gave a JupyterLab introduction at the PyData Paris Meetup.

Another workshop idea would be to bring together the core maintainers of the Jupyter Kernel Message Protocol, developers of different third-party Jupyter kernels, and other interested collaborators to chart the future of this protocol to add different programming languages, debugging, and enhancements. While the maintainers of different Jupyter subprojects are likely to propose workshops, we are hoping that others in the community will propose and organize workshops as well.

The proposal process for these Jupyter Workshops is being managed by the Jupyter Operations Manager, Ana Ruvalcaba (jupyterops@gmail.com), and the Steering Council. Applications are due by August 1, 2018 and our vision is that these events would occur anywhere from September to December of 2018. We encourage you to submit a proposal and complete the following Google Form.

This initiative is organized by Jason Grout, Paul Ivanov, Brian Granger, and Ana Ruvalcaba.

Jupyter receives the ACM Software System Award

2018-05-02T13:01:00+00:00

It is our pleasure to announce that Project Jupyter has been awarded the 2017 ACM Software System Award, a significant honor for the project. We are humbled to join an illustrious list of projects that contains major highlights of computing history, including Unix, TeX, S (R’s predecessor), the Web, Mosaic, Java, INGRES (modern databases) and more.

Officially, the recipients of the award are the fifteen members of the Jupyter steering council as of November 2016, the date of nomination (listed in chronological order of joining the project): Fernando Pérez, Brian Granger, Min Ragan-Kelley, Paul Ivanov, Thomas Kluyver, Jason Grout, Matthias Bussonnier, Damián Avila, Steven Silvester, Jonathan Frederic, Kyle Kelley, Jessica Hamrick, Carol Willing, Sylvain Corlay and Peter Parente.

A tiny subset of the Jupyter contributors and users that made Jupyter possible — Biannual development meeting, 2016, LBNL.

This is the largest team ever to receive this award, and we are delighted that the ACM was willing to recognize that modern collaborative projects are created by large teams, and should be rewarded as such. Still, we emphasize that Jupyter is made possible by many more people than these fifteen recipients. This award honors the large group of contributors and users that has made IPython and Jupyter what they are today. The recipients are stewards of this common good, and it is our responsibility to help this broader community continue to thrive.

Below, we’ll summarize the story of our journey, including the technical and human sides of this effort. You can learn more about Jupyter from our website, and you can meet the vibrant Jupyter community by attending JupyterCon, August 21–25, 2018, in New York City.

In the beginning

Project Jupyter was officially unveiled with its current name in 2014 at the SciPy scientific Python conference. However, Jupyter’s roots date back nearly 17 years to when Fernando Pérez announced his open source IPython project as a graduate student in 2001. IPython provided tools for interactive computing in the Python language (the ‘I’ is for ‘Interactive’), with an emphasis on the exploratory workflow of scientists: run some code, plot and examine some results, think about the next step based on these outcomes, and iterate. IPython itself was born out of merging an initial prototype with Nathan Gray’s LazyPython and Janko Hauser’s IPP, inspired by a 2001 O’Reilly Radar post — collaboration has been part of our DNA since day one.

From those humble beginnings, a community of like-minded scientists grew around IPython. Some contributors have moved on to other endeavors, while others are still at the heart of the project. For example, Brian Granger and Min Ragan-Kelley joined the effort around 2004 and today lead multiple areas of the project. Our team gradually grew, both with members who were able to dedicate significant amounts of effort to the project as well as a larger, but equally significant, “long tail” community of users and contributors.

In 2011, after development of our first interactive client-server tool (our Qt Console), multiple notebook prototypes, and a summer-long coding sprint by Brian Granger, we were able to release the first version of the IPython Notebook. This effort paved the path to our modern architecture and vision of Jupyter.

What is Jupyter?

Project Jupyter develops open source software, standardizes protocols for interactive computing across dozens of programming languages, and defines open formats for communicating results with others.

Interactive computation

On the technical front, Jupyter occupies an interesting area of today’s computing landscape. Our world is flooded with data that requires computers to process, analyze, and manipulate, yet the questions and insights are still the purview of humans. Our tools are explicitly designed for the task of computing interactively, that is, where a human executes code, looks at the results of this execution, and decides the next steps based on these outcomes. Jupyter has become an important part of the daily workflow in research, education, journalism, and industry.

Whether running a quick script at the IPython terminal, or doing a deep dive into a dataset in a Jupyter notebook, our tools aim to make this workflow as fluid, pleasant, and effective as possible. For example, we built powerful completion tools to help you discover the structure of your code and data, a flexible display protocol to show results enriched by the multimedia capabilities of your web browser, and an interactive widget system to let you easily create GUI controls like sliders to explore parameters of your computation. All these tools have evolved from their IPython origins into open, documented protocols that can be implemented in any programming language as a “Jupyter kernel”. There are over 100 Jupyter kernels today, created by many members of the community.

Blazing fast interactive exploration of 1.7 Billion #GaiaDR2 stars in the Jupyter notebook with vaex. https://t.co/DDXzWVBeb2 #dataviz #Python

— Maarten A. Breddels (@maartenbreddels), April 27, 2018

Exploring a large dataset interactively using the widget protocol and tools.

Our experience building and using the Jupyter Notebook application for the last few years has now led to its next-generation successor, JupyterLab, which is now ready for users. JupyterLab is a web application that exposes all the elements above not only as an end-user application, but also as interoperable building blocks designed to enable entirely new workflows. JupyterLab has already been adopted by large scientific projects such as the Large Synoptic Survey Telescope project.

Communicating results

In today’s data-rich world, working with the computer is only half of the picture. Its complement is working with other humans, be it your partners, colleagues, students, clients, or even your future self months down the road. The open Jupyter notebook file format is designed to capture, display and share natural language, code, and results in a single computational narrative. These narratives exist in the tradition of literate programming that dates back to Knuth’s work, but here the focus is weaving computation and data specific to a given problem, in what we sometimes refer to as literate computing. While existing computational systems like Maple, Mathematica and SageMath all informed our experience, our focus in Jupyter has been on the creation of open standardized formats that can benefit the entire scientific community and support the long-term sharing and archiving of computational knowledge, regardless of programming language.

We have also built tools to support Jupyter deployment in multi-user environments, whether a single server in your group or a large cloud deployment supporting thousands of students. JupyterHub and projects that build upon it, like Binder and BinderHub, now support industry deployments, large-scale education, reproducible research, and the seamless sharing of live computational environments.

Data Science class at UC Berkeley, taught using Jupyter.

We are delighted to see, for example, how the LIGO Collaboration, awarded the 2017 Nobel Prize in Physics for the observation of gravitational waves, offers their data and analysis code for the public in the form of Jupyter Notebooks hosted on Binder at their Open Science Center.

Measurement and prediction of gravitational waves formed by two black holes merging. Adapted from https://github.com/minrk/ligo-binder.

Open standards nourish an innovative ecosystem

In Project Jupyter, we have concentrated on standardizing protocols and formats evolved from community needs, independent of any specific implementation. The stability and interoperability of open standards provides a foundation for others to experiment, collaborate, and build tools inspired by their unique goals and perspectives.

For example, while we provide the nbviewer service that renders notebooks from any online source for convenient sharing, many people would rather see their notebooks directly on GitHub. This was not possible originally, but the existence of a well-documented notebook format enabled GitHub to develop their own rendering pipeline, which now shows HTML versions of notebooks rendered in a way that conforms to their security requirements.

Similarly, there exist multiple client applications in addition to the Jupyter Notebook and JupyterLab to create and execute notebooks, each with its own use case and focus: the open source nteract project develops a lightweight desktop application to run notebooks; CoCalc, a startup founded by William Stein, the creator of SageMath, offers a web-based client with real-time collaboration that includes Jupyter alongside SageMath, LaTeX, and tools focused on education; and Google now provides Colaboratory, another web notebook frontend that runs alongside the rest of the Google Documents suite, with execution in the Google Cloud.

These are only a few examples, but they illustrate the value of open protocols and standards: they serve open-source communities, startups, and large corporations equally well. We hope that as the project grows, interested parties will continue to engage with us so we can keep refining these ideas and developing new ones in support of a more interoperable and open ecosystem.

Growing a community

IPython and Jupyter have grown to be the product of thousands of contributors, and the ACM Software System Award should be seen as a recognition of this combined work. Over the years, we evolved from the typical pattern of an ad-hoc assembly of interested people loosely coordinating on a mailing list to a much more structured project. We formalized our governance model and instituted a Steering Council. We continue to evolve these ideas as the project grows, always seeking to ensure the project is welcoming, supports an increasingly diverse community, and helps solidify a foundation for it to be sustainable. This process isn’t unique to Jupyter, and we’ve learned from other larger projects such as Python itself.

Jupyter exists at the intersection of distributed open source development, university-centered research and education, and industry engagement. While the original team came mostly from the academic world, from the start we’ve recognized the value of engaging industry and other partners. This led, for example, to our BSD licensing choice, best articulated by the late John Hunter in 2004. Beyond licensing, we’ve actively sought to maintain a dialog with all these stakeholders:

We are part of the NumFOCUS Foundation, working as part of a rich tapestry of other scientifically-focused open source projects. Jupyter is a portal to many of these tools, and we need the entire ecosystem to remain healthy.
We have obtained significant funding from the Alfred P. Sloan Foundation, the Gordon and Betty Moore Foundation, and the Helmsley Trust.
We engage directly with industry partners. Many of our developers hail from industry: we have ongoing active collaborations with companies such as Bloomberg and Quansight on the development of JupyterLab, and with O’Reilly Media on JupyterCon. We have received funding and direct support in the past from Bloomberg, Microsoft, Google, Anaconda, and others.

The problem of sustainably developing open source software systems of lasting intellectual and technical value, that serve users as diverse as high-school educators, large universities, Nobel prize-winning science teams, startups, and the largest technology companies in the world, is an ongoing challenge. We need to build healthy communities, find significant resources, provide organizational infrastructure, and value professional and personal time invested in open source. There is a rising awareness among volunteers, business leaders, academic promotion and tenure boards, professional organizations, government agencies, and others of the need to support and sustain critical open source projects. We invite you to engage with us as we continue to explore solutions to these needs and build these foundations for the future.

Acknowledgments

The award was given to the above fifteen members of the Steering Council. But this award truly belongs to the community, and we’d like to thank all that have made Jupyter possible, from newcomers to long-term contributors. The project exists to serve the community and wouldn’t be possible without you.

We are grateful for the generous support of our funders. Jupyter’s scale and complexity require dedicated effort, and this would be impossible without the financial resources provided (now and in the past) by the Alfred P. Sloan Foundation, the Gordon and Betty Moore Foundation, the Helmsley Trust, the Simons Foundation, Lawrence Berkeley National Laboratory, the European Union Horizon 2020 program, Anaconda Inc, Bloomberg, Enthought, Google, Microsoft, Rackspace, and O’Reilly Media. Finally, the recipients of the award have been supported by our employers, who often have put faith in the long-term value of this type of work well before the outcomes were evident: Anaconda, Berkeley Lab, Bloomberg, CalPoly, DeepMind, European XFEL, Google, JP Morgan, Netflix, QuantStack, Simula Research Lab, UC Berkeley and Valassis Digital.

JupyterLab is Ready for Users

2018-02-20T13:12:00+00:00

We are proud to announce the beta release series of JupyterLab, the next-generation web-based interface for Project Jupyter.

tl;dr: JupyterLab is ready for daily use (installation, documentation, try it with Binder)

JupyterLab is an interactive development environment for working with notebooks, code, and data.

The Evolution of the Jupyter Notebook

Project Jupyter exists to develop open-source software, open standards, and services for interactive and reproducible computing.

Since 2011, the Jupyter Notebook has been our flagship project for creating reproducible computational narratives. The Jupyter Notebook enables users to create and share documents that combine live code with narrative text, mathematical equations, visualizations, interactive controls, and other rich output. It also provides building blocks for interactive computing with data: a file browser, terminals, and a text editor.

The Jupyter Notebook has become ubiquitous with the rapid growth of data science and machine learning and the rising popularity of open-source software in industry and academia:

Today there are millions of users of the Jupyter Notebook in many domains, from data science and machine learning to music and education. Our international community comes from almost every country on earth.¹
The Jupyter Notebook now supports over 100 programming languages, most of which have been developed by the community.
There are over 1.7 million public Jupyter notebooks hosted on GitHub. Authors are publishing Jupyter notebooks in conjunction with scientific research, academic journals, data journalism, educational courses, and books.

At the same time, the community has faced challenges in using various software workflows with the notebook alone, such as running code from text files interactively. The classic Jupyter Notebook, built on web technologies from 2011, is also difficult to customize and extend.

JupyterLab: Ready for Users

JupyterLab is an interactive development environment for working with notebooks, code and data. Most importantly, JupyterLab has full support for Jupyter notebooks. Additionally, JupyterLab enables you to use text editors, terminals, data file viewers, and other custom components side by side with notebooks in a tabbed work area.

JupyterLab enables you to arrange your work area with notebooks, text files, terminals, and notebook outputs.

JupyterLab provides a high level of integration between notebooks, documents, and activities:

Drag-and-drop to reorder notebook cells and copy them between notebooks.
Run code blocks interactively from text files (.py, .R, .md, .tex, etc.).
Link a code console to a notebook kernel to explore code interactively without cluttering up the notebook with temporary scratch work.
Edit popular file formats with live preview, such as Markdown, JSON, CSV, Vega, VegaLite, and more.

JupyterLab has been over three years in the making, with over 11,000 commits and 2,000 releases of npm and Python packages. Over 100 contributors from the broader community have helped build JupyterLab in addition to our core JupyterLab developers.

To get started, see the JupyterLab documentation for installation instructions and a walk-through, or try JupyterLab with Binder. You can also set up JupyterHub to use JupyterLab.

Customize Your JupyterLab Experience

JupyterLab is built on top of an extension system that enables you to customize and enhance JupyterLab by installing additional extensions. In fact, the builtin functionality of JupyterLab itself (notebooks, terminals, file browser, menu system, etc.) is provided by a set of core extensions.

JupyterLab extensions enable you to work with diverse data formats such as GeoJSON, JSON and CSV.²

Among other things, extensions can:

Provide new themes, file editors and viewers, or renderers for rich outputs in notebooks;
Add menu items, keyboard shortcuts, or advanced settings options;
Provide an API for other extensions to use.

Community-developed extensions on GitHub are tagged with the jupyterlab-extension topic, and currently include file viewers (GeoJSON, FASTA, etc.), Google Drive integration, GitHub browsing, and ipywidgets support.

Develop JupyterLab Extensions

While many JupyterLab users will install additional JupyterLab extensions, some of you will want to develop your own. The extension development API is evolving during the beta release series and will stabilize in JupyterLab 1.0. To start developing a JupyterLab extension, see the JupyterLab Extension Developer Guide and the TypeScript or JavaScript extension templates.

JupyterLab itself is co-developed on top of PhosphorJS, a new Javascript library for building extensible, high-performance, desktop-style web applications. We use modern JavaScript technologies such as TypeScript, React, Lerna, Yarn, and webpack. Unit tests, documentation, consistent coding standards, and user experience research help us maintain a high-quality application.

JupyterLab 1.0 and Beyond

We plan to release JupyterLab 1.0 later in 2018. The beta releases leading up to 1.0 will focus on stabilizing the extension development API, user interface improvements, and additional core features. All releases in the beta series will be stable enough for daily usage.

JupyterLab 1.0 will eventually replace the classic Jupyter Notebook. Throughout this transition, the same notebook document format will be supported by both the classic Notebook and JupyterLab.

Get Involved

There are many ways you can participate in the JupyterLab effort. We welcome contributions from all members of the Jupyter community:

Use our extension development API to make your own JupyterLab extensions. Please add the jupyterlab-extension topic if your extension is hosted on GitHub. We appreciate feedback as we evolve toward a stable API for JupyterLab 1.0.
Contribute to the development, documentation, and design of JupyterLab on GitHub. To get started with development, please see our Contributing Guide and Code of Conduct. We label issues that are ideal for new contributors as “good first issue” or “help wanted”.
Connect with us on our GitHub Issues page or on our Gitter Channel. If you find a bug, have questions, or want to provide feedback, please join the conversation.

We are thrilled to see how you use and extend JupyterLab.

Sincerely,

The JupyterLab Team and Project Jupyter

We thank Bloomberg and Anaconda for their support and collaboration in developing JupyterLab. We also thank the Alfred P. Sloan Foundation, the Gordon and Betty Moore Foundation, and the Helmsley Charitable Trust for their support.

[1] Based on the 249 country codes listed under ISO 3166–1, recent Google analytics data from 2018 indicates that jupyter.org has hosted visitors from 213 countries.

[2] Data visualized in this screenshot is licensed CC-BY-NC 3.0. See http://datacanvas.org/public-transportation/ for more details.

JupyterCon NYC: August 22nd-25th

2017-07-14T18:56:00+00:00

Dear fellow Jovyans,

We’re just weeks away our first Jupyter community conference, JupyterCon. It will take place from August 22nd to 25th (and Sprints 26th), in the beautiful city of New York, at the Hilton Midtown, a spectacular location just steps from Central Park, Times Square, MOMA.

If you haven’t registered yet there’s still time. There are a number of pass options to choose from including 2, 3, or 4 day passes. Discounts are available for students, academic instructors, and government and non-profit employees. Don’t qualify for any of those? We have a special 20% discount for you, just use the code JUPCORE20 when you register.

What is JupyterCon?

The four day event will feature two days of training and tutorials and two days of Keynotes and Sessions. Topics include the Jupyter platform’s core architecture, kernels, extensions & customizations, usage and application of Jupyter Notebooks, as well as sessions on Jupyter’s development and community from the core Jupyter team.

We’ve left plenty of time for networking, including attendee receptions, Speed Networking, Poster Sessions, community group meetups, as well as the chance to meet some of the speakers in small group settings. Check out the event page. The core Jupyter team will also be present and ready to answer your trickiest questions about the Jupyter platform and what’s in-store for the future.

The preconference starts on Monday 21st with a Solar Eclipse from 1:23pm to 4:00 pm in NYC.

A fantastic line-up of speakers

JupyterCon is chaired by Fernando Pérez, creator and BDFL of Jupyter, and Andrew Odewahn, CTO of O’Reilly.

Some of the speakers joining us at JupyterCon include:

Lorena Barba from the George Washington University
Nadia Eghbal from GitHub
Wes McKinney from Two Sigma Investment
Safia Abdalla from the nteract project
Rachel Thomas from Fast.ai
Brett Cannon from Microsoft / the Python Software Fundation

These are only a few of the speakers joining us. We are looking forward to hearing how Jupyter is being used in education, finance, machine learning, and what the future holds for the Jupyter ecosystem. See the full line-up here.

Sprints

Sprints are happening on Saturday 26th, if you want to come hack on Jupyter and related project get more information on the GitHub JupyterCon repository. You do not need to have registered to the main conference — but you must registered via Eventbrite even if you have already register for the main conference.

Financial aid

We had a number of really good applicants for financial help, and the selection process was tough. If you have not been selected this time, don’t be discouraged and we hope to see you at the next JupyterCon.

BOFS

We will have a special “Jupyter for Teaching & Learning BOF“ organized by Lorena Barba And Robert Talbert on Thursday at 7pm. This BOF is for anyone interested in using Jupyter for teaching and learning. Topics for discussion include incorporating Jupyter in the classroom, using Jupyter tools like nbgrader and JupyterHub, connecting with other Jupyter educators, and more. For more information and to let us know you’re interested in participating, please see this flyer and fill out the Call for Participation form at http://bit.ly/jupyter-ed-bof.

Solar Eclipse

If you are coming from outside of the United States please remember to be in NYC on the 21st from 1:23pm as there is a (partial) solar eclipse in NYC, which ends at 4:00.pm. Do not forget your eclipse glasses!

Thanks

This is our first JupyterCon! We do welcome feedback and will be looking for help to organize another one next year. Please contact us if you are interested in helping organizing the next conference.

We’ve partnered with O’Reilly Media to develop the JupyterCon conference. O’Reilly Media is a long-time supporter of the project and active publishers in the Python/Data Science space. O’Reilly has extensive experience running conferences and we’ve been working with them for the past year to bring you a great inaugural JupyterCon.

I also want to thank the members of the Jupyter Con committee as well as the Jupyter Community Members and the team at O’Reilly Media, and all our sponsors for making this conference possible.

You can learn more on the conference website

Introducing the Helm Chart for JupyterHub Deployment with Kubernetes

2017-06-29T23:21:00+00:00

The JupyterHub team proudly announces the release of a helm chart for deploying JupyterHub on Kubernetes clusters. We’ve designed the JupyterHub helm chart to save you time in creating JupyterHub deployments.

You can find a repository with the helm chart here.

This is a pre-release version of the helm-chart. It will likely change in a breaking fashion sometime in the future, though we will make every effort to minimize this as much as possible as modifications are made for new features and increased stability. If you have any questions or comments, reach out to us on Gitter or open an issue. For help with deploying your own JupyterHub instance, see our guide for setting up JupyterHub (which uses this helm chart). Or, come find us at the JupyterHub talk at JupyterCon.

The following principles guided development:

Easy to administer

The nitty gritty of JupyterHub setup and management can be cumbersome, complicated, and time-consuming. With the JupyterHub helm chart, you will spend less time debugging your setup, and more time deploying, customizing to your needs, and successfully running your JupyterHub. Within a cloud computing infrastructure, using the helm chart typically requires only one or two commands to get started.

Open source

The JupyterHub helm chart uses applications and codebases that are open and thriving. We prefer, prioritize, and select tools that have a history of stability and development, and which adhere to open-source principles when it comes to project and community growth. As a result, you’ll be able to easily connect with the many tools available in the open-source community, and you’ll have flexibility in where you deploy JupyterHub.

Cloud agnostic

We’ve made an effort to keep our helm chart as cloud-agnostic as possible. The only requirement is that your computing provider supports the Kubernetes infrastructure, an open-source platform that is widely available across many different online providers. You can run JupyterHub on cloud services such as Google Cloud, Microsoft Azure, and Amazon EC2, and even on your own hardware or institution-specific setup.

Scalable

We’ve taken great care to develop the JupyterHub helm chart with the ability to be used in a variety of work, research, and education settings. Some JupyterHub deployments have a dynamic userbase that works in spurts of activity. Others have users that have long periods of inactivity. Rather than capping the amount of resources available for users, the JupyterHub helm chart utilizes Kubernetes to scale computational resources up (or down) as needed. This means that large changes in user behavior don’t result in system-wide instability or slowdown issues. It also means that you can quickly update user hardware, push new files to user disks, and alter the environment in which users are operating.

JupyterHub has been deployed in a variety of places, including at least one class with nearly 1500 students. We’ve made sure that it can handle large groups of users, and we’re excited to see people push the limit even further.

Support

If you have any questions or comments, reach out to us on Gitter or open an issue. For help with deploying your own JupyterHub instance, see our guide, Zero to JupyterHub. Or, come find us at the JupyterHub talk at JupyterCon.

Acknowledgements

JupyterHub and this helm chart wouldn’t have been possible without the goodwill, time, and funding from a lot of different people. In particular, we want to thank the Gordon and Betty Moore Foundation, the Sloan Foundation, the Helmsley Charitable Trust, the Berkeley Data Science Education Program, and the Wikimedia Foundation for supporting various members of our team. We also want to thank the individuals of the JupyterHub team (listed below), the Project Jupyter community, and our more than 100 contributors for continuing to grow and improve this technology.

Sincerely,
The JupyterHub Team (in alphabetical order)

Berkeley Data Science Education Program (Gunjan Baid, Sam Lau, Ryan Lovett, Yuvi Panda, Vinitra Swamy)

Cal Blueprint Team (Jiefu Gong, Sam Lau, Derrick Mar, Peter Veerman, Tony Yang)

Project Jupyter (Chris Holdgraf, Yuvi Panda, Min Ragan-Kelley, Carol Willing)

Jupyter Blog - Project Jupyter

2026 Jupyter Community Call For Funding Proposals

JupyterLite Officially Joins Project Jupyter!

What is JupyterLite?

The Journey of JupyterLite

A Natural Fit with JupyterLab

Better integration with the rest of Jupyter

Try it in your browser

Acknowledgments and team credits

Project Jupyter’s 2025 Executive Council Elections

Who Are the Newly Elected EC Members?

Creating Open, Sustainable, Leadership

What This Means for Jupyter’s Future

Project Jupyter joins LF Charities

JupyterLab 4.1 and Notebook 7.1 are here 🎉

Custom CSS

Diagrams in Markdown

Inline code completion

Keyboard navigation improvements

Execution history in notebook

Opening files from tracebacks

Error indicator in the table of contents

Plugin Manager

Virtual scrollbar for notebook in windowed mode

Notifications

Full notebook windowing mode improvements

Search improvements

Acknowledgements

JupyterLab 3 end of maintenance

Jupyter Media Strategy & Social Media Update

Summary of announcement

Do you have a message to share with the Jupyter Community?

Jupyter Official Channels

Meet the JMS

Send us your feedback

Recent keyboard navigation improvements in Jupyter

Keyboard navigation in JupyterLab

Notebook Tab Traps

Future accessibility improvements

Feedback

About the Authors

Acknowledgments

Announcing Jupyter Notebook 7

A Familiar Document-Oriented Experience

Visual Debugger

Real-Time Collaboration

Theming and Dark Mode

Improved integration between JupyterLab and Notebook

More features

Why a new version?

Migrating to Notebook 7

Try it on Binder

Acknowledgements

Get Involved

🎉 JupyterCon 2023 recordings now live on YouTube! 🎉

Jupyter Community 2021 Update

New committee announcement

We’re hiring!

Jupyter Community Workshops

JupyterCon

Acknowledgements

About the Authors

Community Note

A visual debugger for Jupyter

A debugger for Jupyter

Try the debugger on binder

Installation

The Jupyter Debug Protocol

New message types for the Control and IOPub channels

Extending the Debug Adapter Protocol

Xeus-python, the first Jupyter Kernel to support debugging

The roadmap of Xeus-python

What about other kernels?

Diving into the debugger front-end architecture

Future developments

Acknowledgements

About the developers

Jupyter Community Workshops 2019 Year in Review

Jupyter Community Workshops 2019

The Future of JupyterCon, 2019 and Beyond