profile
viewpoint

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:

  • https://github.com/microsoft/vscode-python/issues/7805
  • https://github.com/microsoft/vscode-python/issues/2125

Wiki: https://github.com/microsoft/vscode-python/wiki/AB-Experiments

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 https://github.com/microsoft/vscode-python/wiki/AB-Experiments#faq for more details.

Original post

Originally posted by @zor-el in https://github.com/microsoft/vscode-python/pull/12002#issuecomment-643187987

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?

microsoft/vscode-python

Answer questions luabud

Thank you all for providing such a detailed feedback. Let me try to explain a few points:

It imposes a single definition on what is non-transferable on everybody, thereby punishing users who did share those settings in order to satisfy those who didn't (or vice versa).

Our intention is not to punish anyone. We're becoming a very popular extension so we need to be more careful with our settings and solutions. Sharing path settings could be a potential security concern (one of these #7805) so we decided to go for a route where users can still define default settings (in User scope) and then have that to be added by everyone in the team. We're also working on being better at detecting environments, so ideally users won't have to keep setting paths - they'll just be listed in the interpreter list once Select Interpreter is run. And then it's a one click solution per workspace.

It makes it impossible to selectively backup or even look up those settings because there's no defined place where they are readably stored.

The path to the selected interpreter is printed out in the output, so you can always look it up and save that information in your user settings.

It impedes project skeleton generators to cookie-cut a complete project including vscode settings.

In general this doesn't work super well anyway, since paths are OS specific. This only really works for environments that are located in your workspace (and that is more common for virtual environments), but then it doesn't work between Windows and macOS/Linux.

The proposed solution is not general. There are other settings that a user may want to configure isolated to a single work-space that they do not want shared. In such instances, the proposed changes do not help at all.

For choosing what you'd like to share or not, the cleanest solution would have to be provided by VS Code generally.

In the event that an appropriate solution is enabled directly by VS Code proper, there will likely be significant inertia to reverting to the current approach.

We are not going to revert to the python.pythonpath setting as is. Our plan is to deprecate the path settings in the workspace level - but we want to make sure we found a good solution before we implement it.

Environment variables are tricky too since they raise even higher security concerns, so we just can't go that route.

useful!

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