Enhancement: Preferred kernel auto picking

[rebornix]

Currently in VS Code when users open a notebook document, they don't need to pick a kernel manually only in following two scenarios:

• The notebook was opened before and users run the notebook against a kernel already. That kernel will be picked automatically, no other kernel would replace it unless users pick one manually.
• There is only one kernel contributed to this notebook.
  • When users run a cell, and there is still only one kernel, the kernel will be used.
  • Before users run any cell, and there are more than one kernel, the kernel picker will not show any active kernel info (it shows "Select kernel" instead).

Above two scenarios cover two use cases: open an existing notebook, or work on single controller notebook (e.g., GitHub issue notebook). However this doesn't cover two common workflow

1. Users open their existing Jupyter notebook (created through other Jupyter frontend/service) in VS Code
2. Users create new Jupyter notebooks when they have already specified their preferred kernel

Especially that VS Code is still growing to be one of data scientists' Jupyter frontend/editor, almost every new users will run into workflow 1 and do manual kernel picking though often Jupyter has a good guess which kernel is preferred for current document, and also every existing would run into workflow 2.

The concrete issues reported:

1. [AZML/Open in VS Code] on AZML website, click open in VS Code, it opens a remote window and opens the notebook document in the editor. No kernel is not picked though users already specify one in AZML website.
2. Create notebook A in File Explorer, pick a kernel. Create notebook B in File Explorer, the kernel info is back to "Select Kernel" again. Notebooks - Create new notebook not honoring default kernel  #134830 (comment)
3. Create untitled notebook in Editor Area, pick a kernel and run. Save as a new notebook document on disk, the new document has no selected kernel. Notebooks - Kernel Not Saved vscode-jupyter#9512
4. Julia. Create a notebook in JuliaLab, specify a kernel. Open the notebook then in VS Code, preferred kernel not selected. The kernel selection UI should not appear if only one notebook controller is marked as preferred #131370

---

Proposals

For AZML/Julia users, they are mostly working on single language notebook (other than polyglot), meaning the notebook serializer is the ipynb extension we ship out of the core, and kernels/controllers are contributed by a single notebook extension installed from the marketplace (Julia, or .NET, or Jupyter). If this is the case, we can pick the kernel whose affinity is the only highest without prompting users to pick one.

cc @jrieken @mjbvz @DonJayamanne @roblourens

[rebornix]

Had discussions with @mjbvz about this. In addition to the proposal mentioned above (optimizing the single extension contributing multiple kernels scenario), another idea came out of our discussions:

• Allow users to choose the default kernel. One example is users have both Jupyter and Julia extensions and both of them contribute notebook controllers for Julia execution. Users might have their preference for the default kernel, allowing them to specify which kernel should be the default can help avoid users picking the default kernel in every newly opened notebook.

[IanMatthewHuff]

I thought about filing a new feature request on this. But it seemed better to keep the discussion contained here, at least for now. In particular it relates to the last comment about selecting a default kernel as well as the Gear icon for the notebook controller. Speaking personally, the majority of my issues with kernel selection would be alleviated by the ability to select a kernel to be my default, auto-selected kernel at both the global level with the ability to override it at the workspace / resource level, just like the rest of VS Code settings.

All the rest of selection could work like it currently does. But I want the ownership to be able to explicitly specify kernel selection with some type of manual affordance that always trumps any type of heuristics or metadata or forcing a manual selection. At a surface level I like it as just a setting, but the issue here is that controller IDs are not something that's exposed to the User. The Gear icon might be the right place to surface this, and might have even been what the Gear icon did before (it does nothing now for me in insiders).

[rebornix]

But I want the ownership to be able to explicitly specify kernel selection with some type of manual affordance that always trumps any type of heuristics or metadata or forcing a manual selection. At a surface level I like it as just a setting, but the issue here is that controller IDs are not something that's exposed to the User

Agree 100%. Even though we could save the controller id to settings when users use the gear icon, it's not great as users won't be able to read or tweak this specific setting as the controller ids are not always human readable.

With that said, we could tackle this differently to archive the same thing, instead of asking controller id, we could ask users if they want to use the lastly used controller, use a controller suggested by extensions always, use a controller which matches the workspace stats the most (use Julia controller if the workspace stats are all around Julia files).

[jrieken]

Agree 100%. Even though we could save the controller id to settings when users use the gear icon, it's not great as users won't be able to read or tweak this specific setting as the controller ids are not always human readable.

Yeah, that's the challenge here. Controller ids aren't nice to read and not guaranteed to be constant. A better concept is user state, e.g mementos, which also roam across machines. Something already exists but it isn't utilised properly and might need further tweaking. The NotebookKernelService knows and persists what kernel was used most recently for what notebook type. Maybe it's enough to make more brave kernel selections based on that information