Jupyter Server/Kernels Weekly Meeting

  • Zoom: 95228013874 Zoom (pwd: Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1)

  • Historical notes for 2025 and before can be found here.

July 3, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf

Agenda


June 26, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Patrick Chen Google @ptch314
Siddhant Rao Google @rao23
Ian Thomas QuantStack @ianthomas23
Drake Aiman Google @wh1ter4bb1t-js

Agenda


June 19, 2025

No official meeting due to US holiday, but can chat if wanted

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →


June 12, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Patrick Chen Google @ptch314
Jason Grout Databricks @jasongrout
Drake Aiman Google @wh1ter4bb1t-js
Omar Jarjur Google @ojarjur
Boyuan Deng Databricks @dby-tmwctw
Ian Thomas QuantStack @ianthomas23

Agenda

  • [Boyuan] Pre-proposal: Adding optional field execution_state to kernel_info_reply representing shell execution status

    • Document the set of states we expect to support at minimum - the 3 states in the kernel protocol
      • For example, Jupyter Lab and Jupyter server have different set of states.
      • Jupyter server and Jupyter Lab injects their own states
    • Need to prototype for the JEP
    • Consensus from the meeting: positive to move on to JEP, wait a bit (e.g. next Monday) for others to get to the issue async
    • Boyuan will start to write JEP and the prototype
  • [Ian] Subshell status

    • In pre-release 6.30.0a0
    • Ian needs to do some more manual testing of downstream
    • Propose 7.0.0
      • Branches: the current 7.x branch has the anyio implementation, plus a bunch of maintenance branches. Some of these maintenance patches have been backported to 6.x. If we decide to make the current 6.x branch main (for the 7.x release), then we would backport the rest of the maintenance fixes.
      • Branch manipulation can be done by Ian (admin access to ipykernel repo) but will only be done in the presence of another member of the kernel council, possibly Jason or Zach?
    • Is this behind a flag?
    • Probably also need a 6.x branch, from just before the subshells PR was merged.
    • This should be released as actual 6.30.0
    • We may need to maintain the 6.x branch for a while if it is difficult for people to migrate to 7.x, so being able to easily backport to 6.x could be a plus.

June 5, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Omar Jarjur Google @ojarjur
Ian Thomas QuantStack @ianthomas23
Patrick Chen Google @ptch314
Drake Aiman Google @wh1ter4bb1t-js

Agenda

  • [Omar] Failure edge cases for kernel websocket messages getting dropped.

  • Ian - subshells on ipykernel 6.x branch

    • PR https://github.com/ipython/ipykernel/pull/1396 passes all CI and has been approved.
    • Essentially a backport of the 7.x (main branch) implementation, on top of tornado rather than anyio.
    • Plan to merge it shortly, and make pre-release (6.30.0a0 perhaps?) for further downstream testing.
  • [name] Agenda item


May 29, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Omar Jarjur Google @ojarjur
Siddhant Rao Google @siddhantrao
Jason Grout Databricks @jasongrout

Agenda

  • [Siddhant] Discussed the attempts to fix CI/CD for the gateway provisioners repo: https://github.com/jupyter-server/gateway_provisioners/pull/143
    • [Omar] Have made some progress by fixing the conda issue, but I haven't had time to continue digging through the subsequent issues that uncovered. So far they seem to be in two separate categories:
      1. For the 3.8 images, there seems to be some sort of API incompatibility with the jupyterlab/maintainer-tools GitHub action.
      2. For the later OSX images, there seems to be some sort of incompatibility with sbt.

May 22, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Zach Sailer Apple @Zsailer
Ian Thomas QuantStack @ianthomas23
Drake Aiman Google @wh1ter4bb1t-js

Agenda


May 15, 2025

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Patrick Chen Google @ptch314
Jason Grout Databricks @jasongrout
Ian Thomas QuantStack @ianthomas23
Drake Aiman Google @wh1ter4bb1t-js
Omar Jarjur Google @ojarjur
A. T. Darian QuantStack @afshin
Boyuan Deng Databricks @dby-tmwctw

Agenda

  • [Nick] Click has a big problem in 8.2.0 where it ignores default flags. In-progress list of fixes in 8.2.1, which hasn't been released yet.

  • [Boyuan] querying kernel status

    • Can we make a way to poll or query the kernel status?
    • [Vidar] Currently Jupyter frontends send a kernel_info_request, then wait for messages to come back
    • [Omar] Zach has a proposed fix for that, but it's large. Without that fix, if the status message gets dropped, we can get our state machine all out of sync.
    • [Jason] We can use kernel_info_request as a workaround, in the kernel_info_reply we could have some datastructure representing what's the current channel status
    • [Omar] This risks to make protocol backward incompatible, suggested to have another layer of indirection (e.g. Kernel Manager, a kernel tending process) to manage the kernel state
    • [Darian] The kernel status reply could be optional, so it doesn't have to be backwards compatible. In the future version we can make it required
    • A proposal will be raised to make the discussion more concrete
  • [Ian] PR for subshells on ipykernel 6.x branch expected shortly.

    • Subshells (in 7.0) was blocked on anyio changes as well in the kernel
    • Ian now has implemented subshells on top of the async tornado code. It's almost not broken. The 6.x subshells implementation can be experimental.
    • Maybe we release it as ipykernel 7 (without anyio) and bump the current main with anyio to new 8 branch.
  • [Darian] The Jupyter Foundation is working on how to spend the funds in a way to help the community. One possible way is to fund better communication downstream from Jupyter around releases and managing expectations (e.g., how long is a release supported, etc.).

    • [Ian] It would be helpful to scope down, for example ipykernel, to just the bits that we have the capability to actually maintain, and communicate clearly perhaps other parts that are not being so maintained as unsupported unless someone comes in to do that work.
    • For more info about Jupyter Foundation, see its team compass.
Select a repo