Allow user to pick the 'default' kernel when starting

[cassiebreviu]

Environment data

• VS Code Version: Version: 1.57.0-insider (user setup)
  Commit: b4c1bd0
  Date: 2021-06-09T11:49:36.076Z
  Electron: 12.0.9
  Chrome: 89.0.4389.128
  Node.js: 14.16.0
  V8: 8.9.255.25-electron.0
  OS: Windows_NT x64 10.0.19042
  OS Version: Windows 10 20H2 OS Build 19042.1052
• Extension version (available under the Extensions sidebar): v2021.7.922878407-dev
• Python version (& distribution if applicable, e.g. Anaconda): Anaconda
• Type of virtual environment used: conda

When using conda envs with vs code the default selected environment on opening vs code doesn't select the expected environment from either the settings.json or the cmd line. This is surfaced in a couple ways:

1. A common way to select the conda env is thru the cli. However if I activate my conda env in the cli and then open vs code with code . it doesn't respect the conda env I had active. This makes using the jupyter notebook command and going into classic more appealing. It will open Jupyter with my env in my directory with my notebooks ready.

   Steps to Reproduce:

   1. Open command
   2. Type command conda activate myenv
   3. Type command code .
   4. vs code will open with the current directory but the env selected will be whatever env was active from the last notebook in vs code not the one that was activated thru the cli or set for this specific notebook the last time it was opened in vs code.

2. If I open an existing Jupyter notebook in vs code, and select the default conda env. The next time I go into that notebook, it doesn't remember the default env.
   Steps to Reproduce:

   1. Open a notebook in vs code and select the environment
   2. Open a different notebook and select a different environment
   3. Now open the first notebook again, notice it has the environment selected from step 2 (the second notebook) and not the selected environment for the last time that specific notebook was open

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

[IanMatthewHuff]

@cassieview Thanks for the feedback here. Several parts of this sound like a bug that I'm not seeing right now, so apologies, but I might ask a clarifying question or two.

not the one that was activated thru the cli

This is true, and I can split this part out as a possible feature request. The current activated environment in CLI is not taken into account when looking for a preferred notebook kernel.

i or set for this specific notebook the last time it was opened in vs code.

Now open the first notebook again, notice it has the environment selected from step 2 (the second notebook) and not the selected environment for the last time that specific notebook was open

These two sound like symptoms of the same issue. Right now in VS Code - insiders VS Code actually maintains the selection per notebook document so anytime the kernel is manually selected via the kernel picker that should always be preserved, both from the last time VS Code was opened as well as from the last time that the document was opened.

I've been playing around with documents some and I'm unable to get this to repro. Opening and closing VS Code, opening and closing document, selecting a new kernel in a different document. In all those cases the previous kernel that I've selected is still the selected kernel. For the case outlined in point (2) could you pull the "Jupyter" logs from the output window? That could help to diagnose what is going on here.

[IanMatthewHuff]

@cassieview and I chatted offline on this (thanks much Cassie).

The CLI launch sounds like something that we have discussed before with regards to kernel launch speed. Basically a way to launch VS Code from an activated environment and make that just the default for all notebooks that are run. Could be interesting as a command line argument, and we wouldn't even need to load the Python extension.

For the kernel selection not being preserved I believe the main issue here was that VS code is preserving the kernel association as the workspace level. I'm pretty sure this is intentional, but I totally agree that it's strange to open a different folder level and all of a sudden file kernel associations are lost. Our metadata only help set a preferred kernel, it doesn't perform selection.

[greazer]

This issue has to do with rethinking how we present kernels to users. So moving to October and marking as iteration-candidate, since I think there is more here overall.

[IanMatthewHuff]

We've been pulling this issue along for a few milestones. And I believe that the conclusion here is that picking up the env that VS Code is launched in doesn't really match the way that kernel selection is handled in VS Code. Closing this issue down.