Check for ipykernel in New Project Wizard

[sharon-wang]

Intent

• Addresses Project Wizard: detect if ipykernel is installed for the selected interpreter #2856

proj_wiz_check_for_ipykernel.mp4

Approach

• Add new command python.isIpykernelInstalled to the python extension
• Use the new command to check if the selected python interpreter has ipykernel installed
• Always show a note that ipykernel will be installed when a new environment is being created
• If an existing interpreter is being used, show a note that ipykernel will be installed if the selected interpreter doesn't have ipykernel is installed
• Fix an issue with the disabled Next button not maintaining disabled styling

QA Notes

Does not include installing ipykernel during project creation. This will be added in a future PR.

[timtmok]

I don't know if I've got a broken Python environment but the one that I currently use for testing receives the message that ipykernel will be installed. Oddly, an existing Homebrew install (same Python version) does not show the message.

Screen.Recording.2024-04-22.at.5.16.28.PM.mov

[seeM]

Python extension changes LGTM!

[sharon-wang]

I don't know if I've got a broken Python environment but the one that I currently use for testing receives the message that ipykernel will be installed. Oddly, an existing Homebrew install (same Python version) does not show the message.

Screen.Recording.2024-04-22.at.5.16.28.PM.mov

Ah thanks for catching this! I wasn't using Pyenv previously, but I was able to reproduce this issue after setting Pyenv up and using Positron's modal prompt to install ipykernel, then selecting my Pyenv Python interpreter in the wizard.

The issue seems to be that the runtimePath for Pyenv interpreters is aliased (starts with ~/), and something goes wrong in the ipykernel check child process when using the aliased path. The issue also occurs for some of my Conda and Venv environments which also have aliased runtime paths.

Using the extraRuntimeData.pythonPath seems like the way to go (looks to be the same path as runtimePath, but it's an absolute path instead of the ~ home directory alias). I've pushed some commits which include making this change.

Do you mind checking again to see if the issue is still happening for you?

[timtmok]

It worked for me! I did have to eventually restart VS Code before launching a dev Positron. It seemed to not picked up any new environments that I created with pyenv cli until I did that.

[sharon-wang]

It worked for me! I did have to eventually restart VS Code before launching a dev Positron. It seemed to not picked up any new environments that I created with pyenv cli until I did that.

Awesome! For the new environments created not getting picked, I'll have to look into whether that's because the registered runtimes in the runtime service only gets updated during startup (which will require a reload of the IDE) or maybe I need to add another listener for registered runtimes. Alternatively, I could add a "refresh" button so the user can manually refresh the interpreter dropdown list.