Indicate to the user about any conda envs lacking an interpreter which do not use a valid python binary

[greazer]

Version: 1.67.0-insider (user setup)
Commit: a9288be
Date: 2022-04-15T05:16:11.219Z
Electron: 17.4.0
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Windows_NT x64 10.0.22593

Python (pre-release): v2022.5.11051003

Here's my conda env list:

Here's the Select Interpreter list:

Here's the log
MissingEnvironments.txt

[karrtikr]

@greazer Apologies for the issue, does this work in the stable release of the extension?

Unfortunately the logs aren't verbose enough atm, so I will soon create a new VSIX and post it here for you to try out.

[karrtikr]

Here's the VSIX: https://github.com/microsoft/vscode-python/suites/6162882956/artifacts/215887730, please provide the logs again.

EDIT:

We discussed offline that the above VSIX fixes the bug, here's the log:

MissingEnvironments2.txt

[karrtikr]

However some of envs are invalid in the sense they do not contain a valid python binary. So they do not appear in the list.

Error: Command failed: C:\Users\jimg\anaconda3\Scripts\conda.exe run -n jupyter-lab-test-env --no-capture-output --live-stream python c:\Users\jimg\.vscode-insiders\extensions\ms-python.python-2022.5.2185428346-dev\pythonFiles\get_output_via_markers.py -c "import sys;print(sys.executable)"
Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.

It would be nice to somehow indicate this to the user that we did discover these so the conda env list matches with what the extension shows. Turning this into a feature request. This means we either:

• Add support for selecting (and possibly fixing these envs).
• Somehow indicate in the interpreter list that these envs are invalid.
• Showing a notification on discovery, or even popping up a dialog box if the user happens to pick an invalid kernel, stating that it can't be used.

Blockers:

• Internally it is always assumed an environment has an executable.
• We currently validate all envs before displaying them in the list, make sure we skip any type of validation for these envs as they do not have a python binary we can run.

[greazer]

Sounds reasonable to me. Though that last sentence "We currently validate all envs before displaying them in the list". This is related to the conversation we had about a week ago where I believe you were going to experiment with not doing full "validation" (i.e. running the interpreter to get details) and see if anybody cares. I'd assume what that implies is that if an environment is shown in the quick pick and the user selects it, that's when "full validation" could be run. If it's unsuccessful, just tell the user and mark it as inaccessible somehow.

[karrtikr]

Interesting suggestion, will take that into consideration.

where I believe you were going to experiment with not doing full "validation" (i.e. running the interpreter to get details) and see if anybody cares

Just to clarify we actually the arrived to the idea that we'll be reporting the progress state in two phases, one before validating all envs and one after validation finishes, so "not validating experiment" is no longer needed 🙂 That however can change with this issue with your idea.

[brettcannon]

One possibility is popping up a warning notification that the environment list is incomplete and to look at the Output panel for details of what got left out and why.

[luabud]

My 2 cents: If we don't display the interpreter, from the users perspective it may seem like there's a bug in the extension that caused discovery to fail. If we just warn them that the list is incomplete, there's not much they can do to get unblocked. But if we display it (even better alongside an e.g. ⚠️ icon indicating it's a problematic environment), we can show an notification once that is selected saying the binary is invalid and that the user needs to fix (and how wonderful would it be if we could also add a button to fix it? 👀)

[karrtikr]

Add support for selecting (and possibly fixing these envs)

Went with the first solution in #18934 (comment): #18934 (comment)

Also added a ⚠️ icon next to it to indicate it's a problematic environment.

[rzhao271]

I see the warning icon. Filed #19384 as a separate issue.

[karrtikr]

@greazer Can you verify that all envs reported via conda env list are reported? Regardless of whether they point to a valid python binary or not.