Meeting Notes 2024

[Zsailer]

Hello everyone,

Welcome to the Jupyter Server Team!

We meet on Thursdays at 8:00am, Pacific Standard Time on Jupyter's Zoom Channel.You can add yourself to the weekly agenda here. Everyone is welcome!

Let's avoid using this thread for discussion. If you'd like to discuss something in the minutes, open a separate issue and reference this thread.

You can find previous year's notes here: 2020, 2021, 2022, 2023

Meeting Notes

• Dec 19th, 2024
• Dec 12th, 2024
• Dec 5th, 2024
• Nov 28th, 2024 - No meeting, holiday in US.
• Nov 21st, 2024
• Nov 14th, 2024
• Nov 7th, 2024
• Oct 31st, 2024
• Oct 24th, 2024
• Oct 17th, 2024
• Oct 10th, 2024
• Oct 3rd, 2024
• Sept 26th, 2024
• Sept 19th, 2024
• Sept 12th, 2024
• Sept 5th, 2024
• August 29th, 2024
• August 22nd, 2024
• August 15th, 2024
• August 8th, 2024
• August 1st, 2024
• July 25th, 2024
• July 18th, 2024
• July 11th, 2024
• July 4th, 2024 - No meeting (holiday in the US)
• June 27th, 2024
• June 20th, 2024
• June 13th, 2024
• June 6th, 2024
• May 30th, 2024
• May 23rd, 2024
• May 16th, 2024
• May 9th, 2024
• May 2nd, 2024
• April 25th, 2024
• April 18th, 2024
• April 11th, 2024
• April 4th, 2024
• Mar 28th, 2024
• Mar 21st, 2024
• Mar 14th, 2024
• Mar 7th, 2024
• Feb 29th, 2024
• Feb 22nd, 2024
• Feb 15th, 2024
• Feb 8th, 2024
• Feb 1st, 2024
• Jan 25th, 2024
• Jan 18th, 2024
• Jan 11th, 2024
• Jan 4th, 2024

[Zsailer]

January 4th, 2024

Name	affiliation	username
Zach Sailer	Apple	Zsailer
Johan Mabille	QuantStack	@JohanMabille
Andrii Ieroshenko	AWS	@andrii-i
Ian Thomas	QuantStack	@ianthomas23
David Brochart	QuantStack	@davidbrochart

Agenda

• Zach
  • New year, new meeting thread!
  • Membership maintenance check closes tomorrow.
    • Thank you, everyone, for a great year!
  • Port kernel gateway to Jupyter Server 2.x
    • Thank you, Kevin, for doing a majority of the work! 👏
    • Requires a major release (3.x) and maintenance of the old branch (2.x)
    • I will announce on discourse once released.
    • Ran into issues getting the websocket subprotocol working, so the Gateway client defaults to the legacy protocol.
  • Would anyone else like to moderate the Jupyter Server meeting?
  • Also, new year means we should run a fresh election for Jupyter Server representative.

[Zsailer]

January 11th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	Zsailer
Vidar Fauske	JP Morgan Chase	vidartf
Jason Grout	Databricks	@jasongrout
Sylvain Corlay	QuantStack	@QuantStack
Ian Thomas	QuantStack	@ianthomas23
David Brochart	QuantStack	@davidbrochart
Johan Mabille	QuantStack	@JohanMabille
Andrii Ieroshenko	AWS	@andrii-i

Agenda

• Zach

  • schema.jupyter.org progress
    • Add first set of schemas and a simple Python package for distributing schemas jupyter/schema#1
    • Requirements for this repo
      • Installs schemas on disk somewhere (python package?)
        • The current PR uses a Python package
      • Makes schemas available from schema.jupyter.org (permanent URLs)
      • Import schemas at runtime (in any language, in principle)
      • Generate types from schemas in any language, in principle
      • CLI as a Jupyter core application
    • Question: what schemas should go here?
      • event schemas from subprojects
      • specs for connection_file
      • specs for the kernelspec
      • specs for the kernel protocol
      • specs for jupyter mimetypes
      • jupyter_server OpenAPI spec
        • some discussion around this point.
        • there is a difference between the API surface and what the handlers do in response to that API. Maybe we can start by formalizing the API service.
    • Ownership of schemas
      • Which subproject owns this repo?
        • [@jasongrout] Foundations and Standards seems like the natural home
      • Is this the source of truth for schemas? For example, is nbformat the home for the nbformat schema, and it's copied here, or does the official schema live here?
        • [@jasongrout] It's nice having nbformat schema co-located with the tools that work with it, for example. Though I suppose it's not too much of a stretch to have the nbformat package depend on the schemas package.
    • Package versioning
      • Do we ship a separate package for each schema? Or do we bump the package for any schema update?

• Sylvain / Ian: Subshells

  • Add JEP for sub-shells jupyter/enhancement-proposals#91
  • Ian is planning on summarizing the current state of the work over the last few years
  • Two main approaches have been discussed
    • "Subshells": A single thread running a message router to different execution threads
      • Everyone's mental modeling of threading works
    • "Dependent kernels": Multiple execution threads, each with their own ZMQ channels (except control channel is shared), so it appears to the outside world as a collection of independent kernels
      • Pretend like it's a kernel and things "just work"
      • Except lifecycle is slightly more complicated because control thread is shared. For example, what does it mean to shutdown a kernel? Do we shut down the single thread, or the whole process?
  • Ian showed demos of the "dependent kernels" approach
  • There was discussion about how multiple threads interact with status messages. Right now status messages are sent for control message processing, which breaks the mental model for status messages.
  • Are there concerns about multiple threads interacting with the same display objects? Is it possible to do it in a thread safe manner? Or should diplay objects be owned by specific threads? What is the case for multiple clients?
    • [@jasongrout] I used to think the GIL protects us there, but some things I read recently helped me realize Python multithreading can be really tricky. (1, )
      • PEP 703 maybe not always rely on GIL?
  • Possibly in the future, status messages indicate busy/idle status for a single execution thread.
  • What's next?
    • QuantStack has funding to work on this, and is planning on working through the Jupyter process in the next 4-6 months with implementation landing within a year
    • We need to decide the basic approach, so have a discussion and move forward

• David

  • YDrive: CRDT-based contents API
  • Will implement something for JupyterLab for this collaborative drive. Starting today.

[Zsailer]

January 18th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	Zsailer
Johan Mabille	QuantStack	@JohanMabille
Jason Grout	Databricks	@jasongrout
Mike Krassowski	Quansight	@krassowski
Vidar Fauske	JP Morgan Chase	@vidartf
Ian Thomas	QuantStack	@ianthomas23
David Brochart	QuantStack	@davidbrochart
Andrii Ieroshenko	AWS	@andrii-i
William Stein	SageMath, Inc.	@williamstein

• Mike

  • jupyter-lsp vulnerability - please update to 2.2.2 GHSA-4qhp-652w-c22x
    • Thanks to @bollwyvl and Jupyter Security team sheparding the process
    • Should we act on this issue in response: Have handlers be @web.authenticated by default ? jupyter_server#389
  • Ownership of lsp github org
    • jupyter-lsp pointed to ipython-security list, so the user did the right thing
    • ydoc/real-time collaboration has the same server/frontend split confusion
    • Perhaps there is a general correction in the future
      • Move everything into a single org, manage permissions with teams
      • Consolidate and simplify number of orgs
    • Mike enabled GitHub private security reports
    • Tactically: Is jupyter-lsp under Project Jupyter
  • Directing output of out external threads/processes to specific cells Directing output of out external threads/processes to specific cells ipython/ipykernel#1199

• Ian Thomas

  • Update on concurrent kernels (subshells)
  • Add JEP for sub-shells jupyter/enhancement-proposals#91 (comment)
  • We spent ~5 minutes reading the newest update then opened for discussion.
  • Could it be that different dependent kernels have different ip addresses, i.e., totally different connection files?
    • Ian was thinking the connection file for the new dependent kernel just has a different shell port
    • If you have a different ip address, dependent kernels becomes multi-processing instead of multi-threaded
  • Dependent kernels require quite a bit of server changes
  • If we make the feature optional, the dependent kernels may be easier since you don't have to modify the kernel protocol
  • How backwards compatible is the approach for clients that support concurrent kernels, but kernels that don't?
    • subshells: the kernel just ignores the subshell field and messages are considered in order. The guarantee is that messages in a single subshell are processed in order.
    • dependent kernels: the api just hands back
  • the big question i have is how this kernel metadata stored in the notebook format? the notebook document stores compute information in its metadata. will subshells be marked up in the cell metadata to describe compute?
    • For many users, they won't use concurrent execution. Mostly the system uses concurrent execution
  • How are concurrent executions recorded in a notebook? Execution counter? Do different cells store which dependent kernel they use?
  • How does reactive execution work with this? For example, ipyflow (see paper here)

• Community survey for kernels?

[Zsailer]

January 25th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	Zsailer
William Stein	CoCalc/SageMath	@williamstein
Vidar T Fauske	JP Morgan Chase	vidartf
David Brochart	QuantStack	@davidbrochart
Johan mabille	QuantStack	@JohanMabille
Ian Thomas	QuantStack	@ianthomas23
Afshin T. Darian	QuantStack	@afshin
Jason Grout	Databricks	@jasongrout

• Zach

  • Jupyter Server Representative nominations

• Johan

  • Jupyter Kernels Representative nominations (ends February 1st)

• Questions:

  • Is there a Jupyter project wide approach to documenting supported/deprecated Python versions (like NEP 29)?
    • IPython follows https://scientific-python.org/specs/spec-0000/
    • We tend to follow the CPython release cycle.
  • If I write an extension today, can I target JupyterLab only or is there an expectation that I also support the classic notebook?
    • It depends on your audience.
    • There isn't an expectation to write extensions for both.
    • Notebook v7 makes it easier to write extensions that work in both.

• [Ian] Update on concurrent execution? (requested by @jasongrout)

  • Next step: comments from community about what Ian has written
  • If no comments, update the JEP
  • @jasongrout and @Zsailer both have usecases that would benefit from concurrent execution

[Zsailer]

February 1st, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
Michał Krassowski	Quansight	@krassowski
William Stein	SageMath	@williamstein
Ian Thomas	QuantStack	@ianthomas23
Kevin Bates	Veritone	@kevin-bates
David Brochart	QuantStack	@davidbrochart

Agenda

• Mike: resolving path/file ownership API

  • Path resolver API jupyter_server#1331
  • Path resolution by kernel manager and providers jupyter/jupyter_client#1005
    • gateway would need to do more
  • Nick:
    • Can we do this over comms? Wrap the Contents API with comms and sent files over comms to access kernel files.
    • this would avoid creating a new API spec for this purpose. we'd reuse contents API.
    • perhaps the new (proposed) subshell work is another way to do this
    • there would be no gateway issue in this case
  • Where should we continue this conversation?
    • Open an issue in jupyter_client: Exposing kernel contents (file system) via comms jupyter/jupyter_client#1006

• Ian:

  • https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md
  • Has anyone implemented any optional features yet?
    • Not aware of any.
  • Registry of names of such features?
    • Need a schema for current kernelinfo, then extend it for optional features.
    • After meeting found JEP for this: Kernelspec JSON schema jupyter/enhancement-proposals#105

• Kevin:

  • Dependent kernels vs. subshells status?
  • Dependent kernels seems to present an extra challenge when managing kernels.
    • Today, in Jupyter Server, we have MultiKernelManager-->KernelManager
    • This would introduce an additional layer of management, e.g. MultiKernelManager-->KernelManagerShells-->DependentKernelManager
  • Ian: given concerns about dependent kernels, kernel subshells is the current favourite
  • Ian will prepare some instructions for easy use of the demo code so that other maintainers can experiment

[Zsailer]

February 8th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
Johan Mabille	QuantStack	@JohanMabille
Ian Thomas	QuantStack	@ianthomas23
Steve Silvester	MongoDB	@blink103
David Brochart	QuantStack	@davidbrochart
Mike Krassowski	Quansight	@krassowski

Agenda

• Zach

  • Nomination period for Jupyter Server representative ended.
  • Move to voting phase.
    • We don't have an established way to vote. Last year, it was a Google Form, but that isn't anonymous.
    • If we go that route, it shouldn't be managed by people on the ballot.

• Johan

  • voting period for Jupyter Kernels representative has started, the vote is public, on the team compass
  • Nomination phase for JDCs has started

• Mike

  • any comments on Exposing kernel contents (file system) via comms jupyter/jupyter_client#1006?
    • possibly suboptimal for the use case of linkifying tracebacks because we have to go to the kernel and get it
  • preliminary itnent to work on secure by default (opt-in in the current version, possibly opt-out in a future major release) Have handlers be @web.authenticated by default ? jupyter_server#389

• Steve

  • Asyncio story
    • Remove tornado eventloop, while keeping it available for backwards compatibility
    • Async ZMQContext is not compatible
      • Rendering stuck randomly voila-dashboards/voila#1428 (comment)
      • ZMQStream: fd added twice zeromq/pyzmq#1405
    • We should document this limitation in Client 8, and suggest upgrading to Client 9 for a proper fix.
    • Will continue to push ahead with Remove direct usage of tornado jupyter/jupyter_client#997, which needs a bit more work to pass the Jupyter Server 2.0 test suite.

Question:

• What is the current recommended combination for RTC?
  • Currently jupyter-collaboration 2 uses pycrdt-websocket, for pycrdt, which is where development will take place going forward as ypy is not being actively maintained at the moment.
• Discussion about commenting
  • we need Fragment Identification Syntax for Jupyter (linking to cells in document) jupyter/nbformat#317

[Zsailer]

February 15th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
Ian Thomas	QuantStack	@ianthomas23
Jason Grout	Databricks	@jasongrout

• Mike (cannot join)

  • Add an option to have authentication enabled for all endpoints by default

• Zach

  • SSC Rep vote is open: Election of Software Steering Council Representative #59

• Ian: Add JEP for sub-shells jupyter/enhancement-proposals#91

  • Kernel subshells seems like it is a winning proposal.
  • Wording of the JEP has been updated in line with latest thinking, needs review.
  • Dependent kernels might be something we revisit in the future.

• Jason: Invited a bunch of students to the contributing hour. Probably at least 2 will show up???

[Zsailer]

February 22nd, 2024

Name	affiliation	GitHub username
Jason Grout	Databricks	@jasongrout
Sergey Kukhtichev	IBM	@skukhtichev
David Brochart	QuantStack	@davidbrochart
Johan Mabille	QuantStack	@JohanMabille
Ian Thomas	QuantStack	@ianthomas23

Agenda

• Introductions

  • [@jasongrout] BYU-Idaho students last week

    • Fix on Windows!
    • General observation = hard to develop on Windows
    • Nick: DOI important to provide credit for grad students, etc

  • Sergey Kukhtichev

• [@jasongrout] matplotlib and post_execute vs post_run_cell: a complication for subshells

  • Matplotlib-inline corrupted images
  • Comm messages on control channel not really expected
  • Will be PRs from Jason in matplotlib and matplotlib-inline

• Ian - schemas Add first set of schemas and a simple Python package for distributing schemas jupyter/schema#1

  • It appears we have two repos: https://github.com/jupyter-standards/schemas and https://github.com/jupyter/schema
    • NB: Johan just archived https://github.com/jupyter-standards/schemas which was a residue
  • Need some CI to demonstrate its use
  • Nick - start with kernelspec before kernel messages
  • Johan - JEP open for kernelspec, needs a vote at next SSC meeting
  • Suggest *_request and *_reply messages to be in the same schema
  • Structure of directions in final public schema website of e.g. jupyter_client/whatever (2 levels, top one is the project)
  • There is a standard schema for reporting validation errors that we should follow.

[Zsailer]

February 29th, 2024

Name	affiliation	GitHub username
Johan Mabille	QuantStack	@JohanMabille
Vidar T Fauske	JP Morgan Chase	@vidartf
Zach Sailer	Apple	@Zsailer
Steve Silvester	MongoDB	@blink1073
Ian Thomas	QuantStack	@ianthomas23

Agenda

• [Steve] Async Updates across the stack

  • Merged Ian's work to remove control queue from IPykernel
  • Combine this with David's work to remove Tornado IOLoop
  • Steve is working on grafting these two things together, which is proving to be challenging.
  • Zach and Steve are working on getting a new implementation of Async Kernel Manager out to remove ZMQ Stream and Tornado IOLoop.

• [Nick] Schema repo discussion

  • Let's not do any RST for documentation.
  • Markdown forward.
  • That's aim for tooling that works both locally and on CI.
  • Get rid of Makefile
  • Add sphinx autobuild
  • Validate URI of schemas against their location in the repo
  • We should spend some time thinking about URI structure
    • Namespacing shouldn't be a question of "which project owns this schema", such as /jupyter_server/ or jupyter_client
    • Intead, let's namespace based on nouns, e.g. /server/, /kernels/, etc.

[Zsailer]

March 7th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
Jason Grout	Databricks	@jasongrout
David Brochart	QuantStack	@davidbrochart
Ian Thomas	QuantStack	@ianthomas23
Steve Silvester	MongoDB	@blink1073

Agenda

• [Steve] Releases and security updates
  • PR merged in server for enhanced security around release actions
  • Using a Github App for publishing. No longer using Github Admin Token. This also solves the issue of having to regularly update the token.
  • Can't use this for NPM yet.
  • Private release feature in jupyter-releaser (thanks Fred)
    • Useful for security patch releases; using a two part
      1. Publish to PyPI and create a tag.
      2. (1 week later) publish changelong and Github release using a separate workflow
• [@jasongrout] Linux Foundation proposal
  • There is an open issue for discussion.
• [@jasongrout] What is the current status of the prototype for concurrent kernel execution?
  • We might experiment with this at Databricks next week in an engineer hackathon
  • The current prototype is definitely demo code. You can create subshells, you can send execute requests. Potentially the status info is off. The main thread is a router instead of the main execution thread, where it needs to be. You can't delete subshells yet.
  • Anyio prototype is also in progress, and could impact the subshell work. David was working on this, but it has passed over to Steve now. This would make ipykernel asyncio-first, and would simplify future developments. Advantages: support for trio and uvloop.
  • related: AnyIO support in pyzmq
    FEAT: support AnyIO zeromq/pyzmq#1827

[Zsailer]

March 14th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
Ian Thomas	QuantStack	@ianthomas23

Agenda

• [Zach]
  • General announcements for Jupyter Server Team
    • Please read, review, comment (if you'd like) on the move to Linux Foundation proposalLinux Foundation proposal
    • Voting has opened for the Executive Council

[Zsailer]

March 21st, 2024

Name	affiliation	GitHub username
Jason Grout	Databricks	@jasongrout
David Brochart	QuantStack	@davidbrochart
Ian Thomas	QuantStack	@ianthomas23
Omar Jarjur	Google	@ojarjur
Zach Sailer	Apple	@Zsailer
Johan Mabille	QuantStack	@JohanMabille

Agenda

• [Ryan, Gabriel, Jason] Lessons from exploring implementing the subshell demo in Databricks

  • Overall, the demo worked great!
  • Parent headers are per channel (e.g., "control", "shell"), so are inaccurate for subshells. We hacked a parent header per subshell
  • Recent changes for output per thread and eliminating the control queue conflict with the subshell prototype
  • We didn't finish swapping the main thread to be code execution instead of message routing, so interruption still didn't work
  • We added a shell_id parameter to create_subshell_request so we could explicitly set a subshell id (and thereby consolidate subshell ids if desired)
  • We changed the name of the thread to be shell-{name} to aid in debugging
  • Is there a reason we are using zmq/pickling instead of a Python Queue or SimpleQueue to communicate messages between threads?
  • Thread safety issues are tricky (like autocomplete requests might run 3rd party library code that assumes single-threaded)
  • Read up on subinterpreters coming in Python 3.13. Perhaps spawning a subinterpreter is a different kind of subshell, or perhaps subinterpreter is well-suited to a dependent kernel approach

• [Omar] Requesting feedback on Navigating in the JupyterLab UI can prevent idle kernels from being culled. jupyter_server#1360

  • Proposed change ojarjur/jupyter_server@30b45db

Reminder:

• EC council election is currently going on, see your email if you are on a Jupyter council or committee
• Linux Foundation proposal is currently under discussion

[Zsailer]

March 28th, 2024

Name	affiliation	GitHub username
Zach Sailer	Apple	@Zsailer
David Brochart	QuantStack	@davidbrochart
Piyush Jain	AWS	@3coins

Agenda

• Zach

  • I can't host contributing hour today.

• Ryan

  • debugger not working on background thread

• Piyush

• This issue was reported on gitter a few weeks back. Are there any suggestions on how to fix this.

  • Discussed the issue and the next step is to open an issue with all the information. Zach mentioned that this could be a regression from server 1.0, so should try with that. There is also an env variable JUPYTER_SERVER_ROOT which is not configurable at the moment, but could be made into a configurable, which can help nudge the CWD for terminals at runtime.

Bug around inaccurate execution_state in the client
- jupyter-server/jupyter_server#1395
- jupyter-server/jupyter_server#990