Kernel picker shows Interpreter instead of selected kernel (as shown in the toolbar)

Environment data

• VS Code version: 1.55.2
• Jupyter Extension version (available under the Extensions sidebar): v2021.5.745244803
• Python Extension version (available under the Extensions sidebar): v2021.3.680753044
• OS (Windows | Mac | Linux distro) and version: Windows 10 20H2
• Python and/or Anaconda version: Python 3.6.8 (64 bit)
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): NA
• Jupyter server running: Local | Remote | N/A NA

Expected behaviour

The top right hand section should show 3.6.8 (64 bit)

Actual behaviour

The top right hand section shows 3.7.4 (32 bit)

Steps to reproduce:

[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

1. Open a ipynb and let it load. The section shows 3.7.4 (32 bit)

we require Python versions older than 3.7 and of 64 bit to run Deep Learning and OpenCV libraries. But after a recent update, I’ve found that the selected kernel is shown as 3.7.4 (32 bit) in the upper right corner. However when an attempt is made to change the kernel by selecting it, it shows that the current one is 3.6.8 (64 bit) “as it should be”. Seems like it is showing the topmost option out of all available kernels.

Logs

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

XXX

[umeshk-unnik]

I’m glad we found the issue. Not so long ago we used to register interpreters as kernels. But recently we stopped and changed the way we find kernels and interpreters to fix stuff like this. I think this kernel was created by us with the wrong info back then.

I’ll close the issue, but feel free to reopen it happens again.

Sure thing. Was a pleasure providing cover fire. Thanks for the prompt response and effective suggestions. Stay Safe.

[umeshk-unnik]

Here’s a suggestion @umeshk-unnik. Please try moving that python374... kernel to another folder so that the extension doesn’t find it. Then open vscode and on your notebook try selecting your desired kernel on the top right.

Let me know if that fixes it. If it does, maybe we misnamed the python374... kernel.

Well, I renamed the display name and it reflects in the ipynb. However as you suggested, when I remove the entire folder containing the kernel.json file (viz. python374…), all faults seem to be rectified. The notebook runs perfectly like the good ol’ times (with the correct indications).

The files in the Roaming folder seem to be an issue. They mess up the kernel display as well as the options loaded in the kernel selection dropdown as far as I saw. Attaching screen grabs for your reference…