ipykernel 7.0.0 release with subshells

[ianthomas23]

Kernel Subshells in ipykernel 7.0.0

This is a placeholder issue for the ipykernel 7.0.0 release which includes kernel subshells for the first time in a full release, and is due for release on Monday 13th October 2025. This is intended to be the first point of call to obtain information about the release, ask questions and report problems with it.

For those not using subshells it is supposed to be backward compatible with the 6.x branch, but there are some architectural changes such as the use of a separate thread to handle sending and receiving of shell channel messages which may break assumptions made in downstream libraries and hence this is identified as a major releases as it is potentially backwards incompatible. If you experience problems then please report them, and you can pin ipykernel < 7 if necessary.

There have been many discussions, issues and pull requests about subshells over the last few years. Linking to all of these would be overwhelming, so here are a few salient links only. Searching in the ipykernel github repo for "subshells" will give more links.

The original motivation and changes to the Jupyter protocol are in Jupyter Enhancement Proposal 91.

The history in ipykernel is complicated by the original implementation being included with changes from tornado to anyio, but the anyio changes have since been sidelined and the second subshell implementation in the current 7.x branch is on top of tornado. Version numbers in related issues and PRs are therefore not always correct.

ipykernel

• Original implementation in PR Kernel subshells (JEP91) implementation #1249, this has a useful diagram and a list of future changes, such as to execution counts, that need to be made.
• Current implementation in PR Subshells implemented using tornado event loops on 6.x branch #1396.
• Details of branch manipulations in Subshells on 6.x branch #1387 and Ipykernel releases and branches #1399.

jupyterlab

• Subshell support added in Support kernel subshells jupyterlab/jupyterlab#16963. This includes a video and explanation of how you can use subshells in kernels that support them.
• Support for comms over subshells added in If subshells are supported by the kernel, send comm messages to subshells jupyterlab/jupyterlab#17363 and Sort the list of plugins and tokens in the documentation jupyterlab/jupyterlab#17364, including some useful videos. This fixes a problem in ipywidgets (and hence other widget libraries) of widgets not updating whilst the kernel shell is performing a blocking operation.

ipympl

• ipympl 0.9.8 includes Use thread lock to support comms via subshells matplotlib/ipympl#603 to support comms over subshells.

Future work

There is future work to be done supporting the ipykernel 7.0.0 release in downstream projects, and in addressing various issues that need to work with subshells such as those enumerated in the first post of #1249.

[ianthomas23]

ipykernel 7.0.0 released: https://github.com/ipython/ipykernel/releases/tag/v7.0.0.

[bollwyvl]

on conda-forge, with known test failures on python 3.14 vs windows:

• ipykernel v7.0.0 conda-forge/ipykernel-feedstock#196
• https://anaconda.org/conda-forge/ipykernel/files?version=7.0.0

[krassowski]

• JupyterLab integration tests are failing on 7.0 (as they did during the pre-release Integration tests started failing on CI with new ipykernel 7.0 release jupyterlab/jupyterlab#17955), these are broadly in two categories:
  • debugger (teardown?)
  • suggestions from history (presumed performance issues)
• unit tests are failing too, probably because ipykernel is now much slower to startup
• we are getting reports that ipykernel 7.0 is broken for uses on Python 3.14. It's unclear if that happens on all operating systems. Thread: #ask-anything > Jupyter Notebook on VS Code bug?

[ianthomas23]

Ipykernel 7.0.0 was indeed broken on Python 3.14, this is now fixed in release 7.0.1 (as far as I aware).

[faultdiagnosistoolbox]

I encounter problems with matplotlib backends (all I've tried) where the problems seems to be caused by the new version of ipykernel.

How to excite the problem on my machine:
Starting a
jupyter console
and
running the code

%matplotlib tk
import matplotlib.pyplot as plt
plt.figure()

causes a crash with ipykernel v 7.0.0 or 7.0.1.

Downgrading matplotlib and other packages does not fix the problem. If I downgrade ipykernel to 6.30.1 it works as expected.

OS: MacOS
Python: 3.12 and 3.13

[dfalbel]

We have a maybe special use case where we launch IPyKernel from a background thread, eg:

import threading
import time
import asyncio
import sys

from ipykernel.kernelapp import IPKernelApp

old_stdout, old_stderr = sys.stdout, sys.stderr

def launch_kernel() -> None:
    """Create and start an IPython kernel inside this process."""
    app = IPKernelApp.instance()
    if not getattr(app, "_thread_initialized", False):
        # Empty argv -> use the normal TCP transport and pick random ports.
        app.initialize([])
        app._thread_initialized = True  # mark so we don't re-initialize
        print(f"Kernel ready. Connection file: {app.connection_file}")
    try:
        app.start()  # blocks until the IOLoop is told to stop
    except Exception as e:
        sys.stdout, sys.stderr = old_stdout, old_stderr
        print(f"Kernel app encountered an exception: {e}")
        raise

    loop = asyncio.get_event_loop_policy().get_event_loop()
    loop.run_forever()


kernel_thread = threading.Thread(
    target=launch_kernel,
    name="ipykernel-thread",
    daemon=True,
)
kernel_thread.start()

try:
    while kernel_thread.is_alive():
        time.sleep(0.5)
except KeyboardInterrupt:
    app = IPKernelApp.instance()
    app.io_loop.add_callback(app.io_loop.stop)
    kernel_thread.join()

This of coursebreaks the assumption in:

ipykernel/ipykernel/subshell_manager.py

Line 44 in f14b95b

assert current_thread() == main_thread()

I wonder if it would be possible to main_thread() to actually refer to the actual launching thread.

[minrk]

I wonder if it would be possible to main_thread() to actually refer to the actual launching thread.

It should be, we just need to make sure to carry the reference around in the right places.

[dfalbel]

@minrk Indeed, this works for me. I have a local proof of concept. Happy to submit a patch if you think its worth it.

[ianthomas23]

@minrk Indeed, this works for me. I have a local proof of concept. Happy to submit a patch if you think its worth it.

Yes please, a patch would be good. Please include a test also.