I recently set up a new laptop for work and was about to get most of the way using my dotfiles. It’s more than just dotfiles: it is a script to install all my applications and tools. It even configures some of them. Additionally, I use a tool called mackup along with DropBox to sync configuration for almost all my applications. I have Visual Studio Code covered in both of these. As it happened, after I ran the scripts, Visual Studio Code was set up with all my extensions along with Python extensions.
However, something was wrong. VS Code kept on crashing when working on simple Python projects. IDE features would disappear (those given by the Pylance language server) and it would only remain a text editor (a sluggish one at that). A restart helped but only for a short while. Ultimately, I started looking into what extensions were restored and their settings. My assumption was that some of the extensions wouldn’t work properly since this is the new M1 processor (Apple Silicon). I was beginning to clean up the extensions I didn’t need and resetting the configuration. None of this helped.
Problem
The problem was that VS Code didn’t work like an IDE for Python anymore. There was no autocomplete of function suggestions and the IDE behaved sluggishly. Weirdly, even regular editor functions did not work; such as local changes were not being highlighted.
Furthermore, the IDE kept reporting that certain modules were not found. I am using pipenv to manage Python dependencies per project and linters such as pylint and tools like black were installed in a Python venv. Even the modules were installed but VS Code could not find it because it was using the default Python interpreter.
The command to select the Python interpreter would not respond at all. I would only see a message “Activating Extensions…” and that’s it. There would be no selection box to select the Python interpreter.
Experiment – DeprecatePythonPath
I recalled some of the warnings and notices from the initial start-up of VS Code and one of the notices was that the setting python.pythonPath was removed. Instead, a new user setting python.defaultInterpreterPath was introduced in an A/B experiment. The reason this affected me in the new instance was that I was enrolled in the experiment on the fresh installation.
On searching a bit more, I found the documentation for Python environments in VS Code and went about making changes to my configuration. Specifically, I added the new python.defaultInterpreterPath and removed the old setting. This new setting is not available at the workspace level which means we can’t have different settings per project. At first, I thought this would be a problem with different virtual environments. However, the new mechanism is actually better because the current Python interpreter is now stored in the workspace internal state (not settings.json). This means that the machine-specific Python interpreter path does not need to go into the workspace’s settings.json at all. The documentation page for this experiment outlines this clearly.
A VSCode internal storage is introduced which will now store the interpreter settings in the workspace & workspace folder scope. i.e workspace settings are no longer stored in settings.json/.code-workspace, but an internal storage.
Additionally, I added the setting for python.venvPath and set it to pipenv‘s base path (in my case, this was ~/.local/share/virtualenvs/). This sped up the “Select Interpreter” command and let me select the correct interpreter for each project. Moreover, changes to the interpreter wouldn’t affect the .vscode/settings.json file which means my machine-specific path wouldn’t end up in the git repository.
I hope this post was useful if you are facing similar problems. My intention in writing this was documenting my own findings and understanding them better. I feel I could have done a better job in explaining the problem here but this will have to do for now. If you have questions, ask via comment or on Twitter and I will do my best to help.