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 #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 #1396.
• Details of branch manipulations in #1387 and #1399.

jupyterlab

• Subshell support added in 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 jupyterlab/jupyterlab#17363 and 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 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:

• https://github.com/conda-forge/ipykernel-feedstock/pull/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 https://github.com/jupyterlab/jupyterlab/issues/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:

https://github.com/ipython/ipykernel/blob/f14b95bd54888eeaee4e70d9232e188638addc35/ipykernel/subshell_manager.py#L44

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.

[simonkeys]

I found a problem that occurs with ipykernel 7.0 but not with 6.31.

pyqtgraph has a feature that uses jupyter_rfb to display Qt graphics (I'm using PySide6) in Jupyter Lab. Somewhere in this process there is an issue with calls to different threads:

The error occurs when mousing over the generated widget.

I'm not sure which of these projects I should report the issue to...

Code is

import PySide6
import pyqtgraph as pg
from pyqtgraph.jupyter import GraphicsLayoutWidget
qtApp = pg.mkQApp()

GraphicsLayoutWidget()

I'm using

ipykernel                 7.1.0
jupyter-rfb               0.5.3
jupyterlab                4.5.0
PySide6                   6.10.0
pyqtgraph                 0.14.0

[ianthomas23]

@simonkeys Thanks for reporting.

With ipykernel >= 7 and jupyterlab >= 4.4.4 then ipywidgets (the base package that pyqtgraph.GraphicsLayoutWidget and jupyter_rfb.RemoteFrameBuffer use) uses subshells for comms, which means that the callback code used to update the widget to show the graphics is running in a separate thread, not the main thread, by default. This is strictly prohibited by windowing toolkits such as Qt as the error message indicates.

To progress, you can disable the use of "Kernel comms over subshells" in the JupyterLab Settings Editor, change it to "Disabled" in the screenshot below:

Longer term, how could this situation be improved? Probably the simplest and quickest fix would be for pyqtgraph to check what thread is running the widget callback code, and if it is not the main Qt thread to signal that thread to run the update instead. Then Qt will be happy.

There is an alternative of allowing individual comms to override the JupyterLab setting and not use subshells. But the plumbing for that through ipywidgets and jupyterlab isn't simple, and it would require changes in pyqtgraph/jupyter_rfb anyway.