Ask questionsDetails on the A/B experiment removing `python.pythonPath` support
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.
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.
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.pythonPathfrom 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
pythonPathwould 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.jsonthat 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
pythonPathremoval 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.pythonPathfor 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
pythonPathcaching behavior could remain intact, but an explicit
pythonPathsetting could take precedence?
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.