Connect to existing Local Kernel

FYI - This feature is for the scratch path.

Connecting to exiting live remote kernels is simple:

• When we detect remote kernels we create a controller for that live remote kernel
• Then we select that remote kernel controller in a notebook/IW

For local kernels, we have no such concept - we must create a controller that points to the live local kernel. Suggestions

• Option 1: When we start a kernel, we could then create a controller that points to this active kernel (similar to live remote kernels)
• Option 2: When starting a scratch pad, we can first create the controller and then attach the controller to the notebook

Notes:

• How can user start a notebook that points to the same local live kernel?
  • We need option 1 for this.
• How can user start an IW that points to the same local live kernel?
  • We need option 1 for this.
• What is the life time of this controller?
  • Rmemeber - this is a local live kernel.
  • If all notebooks/IW that connect to this controller are closed, then kill off the kernel (as is done today) & delete this controller.
  • However if the kernel was originally started by a 3rd party exetnsion then don’t do anything (in that case the lifetime of the kernel/controller is managed by the 3rd party extension).
  • If the kernel dies (3rd party closes this or we kill it), then remove the controller from the list (e.g. if user kills the kernel from kernel management UI).
• Do we have multiple IKernel instances?
  • No, we’ll have just the one IKernel instance.
• Where do we list these live local kernels
  • Just as with live remote kernels, we’ll have a separate section for live local kernels.
• Interrupts/restarts/cell execution all share the same kernel
  • Thus if we restart the kernel in scratch pad, that will restart the kernel in the other notebook/iw (where the kernel was originally started)
  • Similarly execution in scratch pad will end up getting queued along with the other cells. I.e. if we have a few cells running in the original notebook, and we create a scratch pad, and run cells in this scratch pad, they will end up getting queued in the same queue (after all its the same kernel).

Thoughts:

• Go with option 2, if and when users ask for option 1, we can add support for that
• Even with Option 2, we still need to create an controller and display it in the list (meaning we still need an entry under Live Local Kernels), which is the same as Option 1. However this controller is created only when creating a scratch pad (we’ll expose a simple API or simple command to make this possible in Jupyter ext).

[DonJayamanne]

Outcome:

• When connecting to a local kernel add an entry for the live local kernel in kernel list (for insiders)
• If we connect to a live local kernel and the original notebook/iw is closed, then kill off the corresponding kernel
  • If users complain we can change this later

For now, enable this feature only in the pre-release (insider version).

[vttrifonov]

I use the ipynb for presentation (cells with few lines of code and explanation around them) and py code with all complexities (making widgets, generating data, plots, etc) is separate. I work mostly within VSCode and use Jupyter rarely… I usually work on code and presentation/notebook in parallel going back and forth. I will nibble at the code and add a cell that captures the gist. Vice versa, I can prototype within the notebook and then move it to the code. Either way having a connection between IW and the notebook is a boon. In my current workflow, I run a remote (mostly localhost) Jupyter outside of VSCode and then connect the notebook and the IW to this remote. It works fine but needless to say having to run Jupyter outside, get the URL, paste in VSCode, etc is a nuisance… Sometimes I start with the IW and then connect the notebook to it (IW shows as default.ipynb notebook). Sometimes the other way around.

It seems natural to provide the same functionality within VSCode (perhaps as a new type of remote: a local virtual kernel)