Select interpreter popup does not shown any system, pyenv or virtualenv choice. #15439
Comments
erongd
added
triage-needed
|
Can also confirm this is happening to us. Rolling back to the previous version of the python extension fixes it for now. |
|
+1. Have rolled back for now. |
|
+1 For me as well. The "Python: Select Interpreter" dialog does not list any of the pyenv virtualenv environments. |
|
Have you manually opted into experiments? Check for this setting |
|
My python.experiments.optInto was empty.
…On Thu, 18 Feb 2021 at 16:58, Karthik Nadig ***@***.***> wrote:
Have you manually opted into experiments? Check for this setting "python.experiments.optInto"
= ["All"]. We have a new discovery mechanism, and it might be failing.
You can opt into specific experiments if you need that. If you are NOT
opted in any experiment let us know, there might be some interference going
on with the new discovery module and the old one.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#15439 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQBK25UEXLLIWE2XW5V5LIDS7VBJVANCNFSM4XZYDJJA>
.
|
|
@braineruption Can you try this and see if it helps? |
karthiknadig
added
area-environments
ghost
removed
the
|
I don't see any difference between having or not. |
|
@albireox Can you share the paths to the interpreters that it is failing to detect? Also, can you share |
|
It seems to be failing to detect all the pyenv virtualenvs from installations that are not conda. Apparently it finds the pyenv installations and venvs from conda:
but not others such as And the environment variables
My system also has Python installations from homebrew, but I don't use them for development. |
|
@albireox thanks for details. I am able to repro the issue. Can you share the output of |
|
|
I tried the pythonDiscoveryModule but that made no difference. What's missing for me are the Homebrew installed pythons and the pyenv virtual envs, i.e. all the installations that are sym-linked. |
@karthiknadig: Yes, that's the problem I'm seing. The "base" pyenv-versions show up, but not the virtual environments based on the base versions. And they are all symlinks: |
|
I mentioned in Issue #15457 that I am having the opposite problem on Windows 10 with WSL 2, using visual studio code insiders. I finally managed to set up pyenv so that pyenv shims come first in the path, and added a symlink so that python in Now, however, in visual studio code insiders, the system python doesn't show up as an available interpreter (which I would imagine should be found automatically in |
|
I have this issue too. And this is python interpreter in vscode. |
|
@brybalicious That sounds like a different issue. Please file a separate bug. |
|
@Aiden-Jeon Can you confirm that you don't have any experiments that you have opted into? check for |
|
If you're having the issue described in the OP, please add the thumbs-up (👍 ) reaction to the OP so this issue has more visibility. |
|
I'm having the same issue. It seems that the discovery mechanism isn't able to follow symlinks any more. A workaround that I've found is to use "Enter Interpreter Path..." and enter the full path to the env's binary without going through the symlink. For example, to use the venv $ ls -l ~/.pyenv/versions/my-env
lrwxr-xr-x 1 rob staff 42 Feb 19 11:02 ~/.pyenv/versions/my-env -> ~/.pyenv/versions/3.8.6/envs/my-envIn the "Enter Interpreter Path..." input, use: |
|
This seems fixed to me in the latest |
|
We just pushed a point release with a fix for this. Please try and let us know. |
|
Point release also works for me. |
|
Point release also works for me too. |
|
Works for me, thanks! |
|
Glad it worked, closing this now. If it still happens let us know and we'll reopen the issue. |
|
Do not work for me. 😢 |
|
Yup, worked for me too. Thanks for the quick turnaround. |
|
@LeoAzLiu
|
|
@karthiknadig Thanks a lot. It works great! By the way I think the pyenv-win is supported. Why the issue #15304 is still marked as "needs decision"? It is just a little confuse. But it is OK. It works! Thanks again! 👍 |
|
For my case, What it was worked: |
For me it worked on windows. I used "python.defaultInterpreterPath": "%USERPROFILE%.pyenv\pyenv-win\bin" |
Environment data
python.languageServersetting: Microsoft[NOTE: If you suspect that your issue is related to the Microsoft Python Language Server (
python.languageServer: 'Microsoft'), please download our new language server Pylance from the VS Code marketplace to see if that fixes your issue]Expected behaviour
When click on select interpreter, the popup should shown all installed python interpreter including system, brew, pyenv and also virtualenv created under pyenv.
Actual behaviour
The select interpreter popup only shown the one interpreter under "/usr/bin/python3", no other interpreters shown like it use to be. However if manually select the desired interpreter/virtualenv through the system dialog box, everything else in python development seems to work just fine.
The extension output the following in the output window complaining of not able to resolve symbolic link, even though all those symbolic link are valid and create by default installation methods include system, brew or pyenv.
Error 2021-02-17 22:56:52: Failed to resolve symbolic link: [Error: ENOENT: no such file or directory, lstat '../../System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7'] {
errno: -2,
code: 'ENOENT',
syscall: 'lstat',
path: '../../System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7'
}
Error 2021-02-17 22:56:52: Failed to resolve symbolic link: [Error: ENOENT: no such file or directory, lstat '../Cellar/[email protected]/3.9.1_8/bin/python3'] {
errno: -2,
code: 'ENOENT',
syscall: 'lstat',
path: '../Cellar/[email protected]/3.9.1_8/bin/python3'
}
Error 2021-02-17 22:56:52: Failed to resolve symbolic link: [Error: ENOENT: no such file or directory, lstat '../Cellar/[email protected]/3.9.1_8/bin/python3.9'] {
errno: -2,
code: 'ENOENT',
syscall: 'lstat',
path: '../Cellar/[email protected]/3.9.1_8/bin/python3.9'
}
BTW, I tested the same setup on linux or windows, it works fine.
The text was updated successfully, but these errors were encountered: