Concrete issue I'm having: on windows, when using miniforge, installed non system-wide but with the option "register miniforge as my default python..." checked (i.e. miniforge path added to registry key Computer\HKEY_CURRENT_USER\Software\Python\PythonCore\3.12\PythonPath), the environments created with miniforge are correctly detected by the extension, but if one of these environments is selected to show its packages or as working environment, the following error is obtained:

"Failed to run "conda list -p c:\Users\xxx\miniforge3\envs\xxx":
The system cannot find the path specified.

From the extension's log output:

[info] Using conda from persistent state: C:\Users\xxx\miniconda3\Scripts\conda.exe
⋮
[info] Discovered manager: (Conda) C:\Users\xxx\miniforge3\Scripts\conda.exe
⋮
[info] Discovered env: C:\Users\xxx\miniforge3\envs\xxx\python.exe
⋮
[info] Using conda from cache: C:\Users\abdel\miniconda3\Scripts\conda.exe
[error] Conda hook not found in any of the expected locations: C:\Users\xxx\miniconda3\shell\condabin, C:\Users\xxx\miniconda3\Library\shell\condabin, C:\Users\xxx\miniconda3\condabin, C:\Users\xxx\miniconda3\etc\profile.d, given conda path: C:\Users\xxx\miniconda3\Scripts\conda.exe

which shows that the issue is by using the conda path from "cache". One suggestion is to check for path existence before setting this "cache", or by modifying getCondaExecutable

to test if path exists before early return.

This could solve problems like #206 where the path from "cache" (which is the first check in getCondaExecutable) is a generic/default path I think, which doesn't necessarily exist. If we check for path existence before returning, we can explore the other non-"cache" sources...

A related PR that possibly fixes the issue (I haven't looked at the details): #675 (issue #674).