Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jupyter Client 8 Release Planning #833

Closed
blink1073 opened this issue Sep 12, 2022 · 9 comments
Closed

Jupyter Client 8 Release Planning #833

blink1073 opened this issue Sep 12, 2022 · 9 comments
Milestone

Comments

@blink1073
Copy link
Contributor

blink1073 commented Sep 12, 2022

@blink1073
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@blink1073
Copy link
Contributor Author

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

@kreuzert
Copy link

kreuzert commented Dec 1, 2022

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
Copy link
Contributor Author

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

@blink1073
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@mathbunnyru
Copy link
Member

mathbunnyru commented Feb 28, 2023

@blink1073 I suppose this can be closed.

@blink1073
Copy link
Contributor Author

Thanks @mathbunnyru, yes.

@blink1073 blink1073 unpinned this issue Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants