jupyter_client
jupyter_client copied to clipboard
Jupyter Client 8 Release Planning
- 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 https://github.com/jupyter/jupyter_client/issues/755 and https://github.com/jupyter-server/team-compass/issues/15#issuecomment-1090141029
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
readypromise with astatus: Unicodetrait 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 canobserve()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.
I updated the top level comment to reflect our reduced scope to only change what is necessary.
https://github.com/jupyter/jupyter_client/releases/tag/v8.0.0a0
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?
We still have a check for an existing kernel here. @Zsailer what do you think of adding a ready wait there?
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.
I plan to make an RC on Monday 19 Dec and then a final release notionally on Mon 9 Jan.
@blink1073 I suppose this can be closed.
Thanks @mathbunnyru, yes.