Replies: 1 comment
-
|
That looks like an old version of the python extension. Can you update it to the latest? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
(I'm using Cursor not VSCode, and neither of the command palate bug reports work, so please let me know if there's a better way than this to file the bug)
Environment
/usr/bin/python3(system, 3.9.6)/Library/Frameworks/Python.framework/Versions/2.7/(from 2015, i386/x86_64 binaries)/usr/local/bin/Bug
The status bar shows "Discovering Python Interpreters" with an infinite spinner that never completes, even after leaving the editor open for days. The
pythonLocatorcache directory (globalStorage/ms-python.python/pythonLocator/) remains permanently empty — the scan never finishes or writes results.Steps to reproduce
What I've tried (none of these resolve it)
python.defaultInterpreterPathto a valid binarypython.locatorto"js"python.experiments.enabledtofalsepython.condaPath,python.venvPath,python.poetryPath,python.pipenvPath,python.activeStateToolPath,python.pixiToolPathpython.venvFoldersto[]python.interpreter.infoVisibilityto"never"Expected behavior
python.defaultInterpreterPathset, the extension should use that interpreter immediately without blocking on discovery.python.locatorsetting should be respected. It appears to be taggedonExP/previewinpackage.json, suggesting the nativepetbinary may be force-enabled via an A/B experiment flag, overriding the user's explicit setting.petbinary (python-env-tools/bin/pet) should not hang indefinitely — it likely gets stuck probing legacy Python 2.7 i386/x86_64 binaries on ARM macOS, or iterating pyenv shims.Additional context
Setting
python.experiments.enabledtofalsealso had no effect, further suggesting the native locator is being force-enabled outside of user-controllable settings.Beta Was this translation helpful? Give feedback.
All reactions