Jupyter Client 8 Release Planning

[blink1073]

• Fix handling of pending kernels - use future created in constructor
• Asyncio refactor - remove use of nest_asyncio, create separate synchronous managers and deprecate them. cf Clean up synchronous managers #755 and Meeting Notes 2022 jupyter-server/team-compass#15 (comment)

[blink1073]

Talking more in last week's server meeting, we'd like to keep Jupyter Client as minimal as possible and make any extra changes in Server. I propose we do the following for 8.0:

• Revert the Jupyter Event addition
• Replace the ready promise with a status: Unicode trait that takes the form: self.status = 'post_start_kernel:start', where we set the status at the start and end of each method. Then, anyone wishing to build events or listeners on top of that status can observe() the trait.
• Defer the monitor to Jupyter Server.

That leaves us with the nest-asyncio removal and the ready -> status change as the two things for 8.0, both of which are minor impact for most consumers, considering that pending_kernels was opt-in and experimental.

[blink1073]

I updated the top level comment to reflect our reduced scope to only change what is necessary.

[blink1073]

https://github.com/jupyter/jupyter_client/releases/tag/v8.0.0a0

[kreuzert]

We're using use_pending_kernels=true and the AsyncMultiKernelManager with jupyter_client in version 7.1.2 .
With this setup, we're unable to interrupt Kernels which are not fully started yet. Will this be possible in version 8?

[blink1073]

We still have a check for an existing kernel here. @Zsailer what do you think of adding a ready wait there?

[blink1073]

We talked about this today in the server meeting, and agreed it makes sense to allow a delayed interrupt, for the case when you "Restart and Run All" and want to interrupt execution.

[blink1073]

I plan to make an RC on Monday 19 Dec and then a final release notionally on Mon 9 Jan.

[mathbunnyru]

@blink1073 I suppose this can be closed.

[blink1073]

Thanks @mathbunnyru, yes.