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

Tracking release 7.0 changes #642

Closed
14 tasks done
kevin-bates opened this issue Apr 12, 2021 · 7 comments
Closed
14 tasks done

Tracking release 7.0 changes #642

kevin-bates opened this issue Apr 12, 2021 · 7 comments
Milestone

Comments

@kevin-bates
Copy link
Member

kevin-bates commented Apr 12, 2021

Since we will be delivering a major release (7.0), I'm hoping we can use this issue to track changes that might affect existing applications. We should, at this time, go ahead and remove deprecations that have been in place as well as other api-changes (preferably minor in nature).

The following are needed for Kernel Provisioning. If Kernel Provisioning is not in the initial 7.0 release, it would be good if these could be included in 7.0, to enable Kernel Provisioning's introduction in a minor release:

We should probably talk about branching as well. I guess we'll keep working off the tip and create a 6.x branch against the appropriate tag once a 6.x PR is required.

@kevin-bates
Copy link
Member Author

kevin-bates commented Aug 3, 2021

Here's an attempt to document the API changes mostly brought about by the Kernel Provisioning changes (#612). This content will need to be relocated but I wanted to get an initial form persisted somewhere.

API Changes

All of the API changes for KernelManager and AsyncKernelManager in the 7.0 release were confined to internal public methods, which we define as methods called from the formally public methods but could be overridden in subclass implementations. As a result, these changes may impact subclasses of KernelManager or AsyncKernelManager provided those implementations also implement or call these methods, but should not affect applications that call only the formally public methods.

KernelManager

The following internal methods had signature changes:

  • def pre_start_kernel(self, **kwargs) -> Tuple[List[str], Dict[str, Any]]:

    • pre_start_kernel now returns a tuple consisting of the formatted kernel startup list and an updated set of keyword arguments.
  • def _launch_kernel(self, kernel_cmd: List[str], **kw) -> None:

    • _launch_kernel now returns None instead of the Popen instance
  • These methods now take the keyword argument restart indicating the shutdown was on behalf of a kernel restart (when True).

    • def finish_shutdown(self, restart: bool = False):
    • def _kill_kernel(self, restart: bool = False):
    • def _send_kernel_sigterm(self, restart: bool = False):
  • Attribute kernel has been removed and logically replaced with provisioner - which is an instance of KernelProvisionerBase and can be viewed as an abstract Popen instance.

AsyncKernelManager

Besides the signature and attribute changes described above, the following internal methods were made async for AsyncKernelManager:

  • async def pre_start_kernel(self, **kwargs) -> Tuple[List[str], Dict[str, Any]]:
  • async def post_start_kernel(self, **kwargs)
  • async def request_shutdown(self, restart: bool = False):
  • async def cleanup_resources(self, restart: bool = False):

ZMQSocketChannel

  • async def get_msg(self, timeout: t.Optional[float] = None) -> t.Dict[str, t.Any]::
    We dropped the block: bool = True keyword argument. Calling this method with block=False previously translates to calling it with timeout=0 now.

Deprecations removed

Method KernelManager.cleanup()

The cleanup() method on KernelManager has been removed. cleanup_resources(restart: bool = False) should be used.

Attribute KernelManager.kernel_cmd

This attribute had been marked for deprecation for 4 years. The command used to start the kernel is derived from the argv stanza of the kernel specification file (kernel.json).

@blink1073
Copy link
Contributor

I'm working on the allowlist changes, so that leaves documentation as the last item we're tracking. I'll cut an rc once we get the allowlist changes in.

@blink1073
Copy link
Contributor

RC coming tomorrow morning US time.

@blink1073 blink1073 pinned this issue Aug 5, 2021
@blink1073
Copy link
Contributor

https://pypi.org/project/jupyter-client/7.0.0rc0/

@blink1073
Copy link
Contributor

Let's aim for a final release on Mon Aug 16

@blink1073
Copy link
Contributor

Let's hold off on the release until #644 is finished

@blink1073
Copy link
Contributor

Looks like we're good! I'll handle the changelog and cut the release after getting lunch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants