Ask questionsDetails on the A/B experiment removing `python.pythonPath` support

Summary of the situation

For security reasons we need to not automatically trust the python.pythonPath setting when it originates from a .vscode/settings.json file in a workspace. We also had a long-standing request to not write a user's environment path to .vscode/settings.json to allow for it to be committed to version control without be specific to any one user's machine.

We set up an A/B experiment to measure impact on users in dropping support for python.pythonPath. This issue is a response from users who were negatively impacted. We are working with various teams within Microsoft to try and come up with a situation where we can bring back some semblance of the old semantics while still providing the level of security and safety we need to.

To stay updated on our work to resolve the situation, please feel free to subscribe to this issue -- there's a "Subscribe" button in the right column -- and we will post updates to this issue as things develop.

Related issues:



Opting out of the experimental semantics

To opt out of the experiment, you can set “python.experiments.optOutFrom” to either the specific experiment or to ["All"] to opt out of all experiments. See for more details.

Original post

Originally posted by @zor-el in

I'm posting this coming from #2125 because that issue is referenced from the announcing blog post.

Complete removal of python.pythonPath from the settings is a massively breaking change that IMO isn't warranted by the #2125 issue that has been used to justify it in the above blog post. (This change has certainly been breaking things left and right for me.) The explanation in that blog post's comment that "it can be useful" doesn't invalidate my argument. A breaking change is harmful, so it should be significantly outweighed by a benefit that cannot by obtained otherwise. This is not the case here though, IMO.

Although it is true that pythonPath would likely be different for different people, I'd argue that is true for the entire (or most of) .vscode/settings.json. For example, extensions can and do store settings in .vscode/settings.json that may just as well conflict with other users.

Settings are not generally transferable from user to user and from machine to machine, so there is little point in sharing them. In those cases that one would want to share them, one would certainly want to separate transferable from non-transferable settings.

Note the OP's issue wasn't the existence of python.pythonPath, but the unsolicited modification of .vscode/settings.json, which sneaks in non-transferable content into (in their case) shared settings.

Apparently the underlying issue is the lack of means for separation of transferable from non-transferable settings. That separation is inadequately addressed by removal of pythonPath (it is a general issue, not one specific to Python). The concrete issue #2125 is not about pythonPath removal either but about unsolicited modification of .vscode/settings.json. That is just as inadequately addressed by mere removal of pythonPath (IMO it could have been solved without breaking everybody's settings).

Question: Why can we not keep python.pythonPath for backward compatibility and simply ask the user for permission to overwrite it (and hint at the fact that the setting may not be transferable)?

Perhaps even the experiment's pythonPath caching behavior could remain intact, but an explicit pythonPath setting could take precedence?


Answer questions karrtikr

@jraygauthier Maybe, although that seems like much more work. Please take these discussions to #12665

@zor-el @williamcol3 I found one of the security concerns which motivated this solution for your reference. This was brought to us by the security team at Microsoft and independently by external people.


Related questions

Auto Scroll in the Jupyter output hot 3
Workspace contains pipfile but pipenv --venv failed hot 2
Can you turn off the Microsoft Python Language Server? hot 2
Unable to debug Python tests (duplicate entries in "env") hot 2
Jupyter server crashed. Unable to connect. Cannot assign requested address hot 2
Auto Scroll in the Jupyter output hot 2
Unable to run launch targets with newest VS Code Python extension hot 2
Unable to start jupyter python interactive window hot 1
HBox output is not shown correctly in the interactive window hot 1
Debug -> Add Debug Configuration 'Cannot read property openConfigFile' hot 1
VSCode cannot connect to jupyter server; with browser this works fine hot 1
Linux arm64/aarch64 support hot 1
Add setting to disable icon for "Run Python File In Terminal" hot 1
Extension Host keeps crashing hot 1
Activate environment before debugging tests hot 1
Github User Rank List