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 karrtikr
Would it be possible to have a versionable setting
For now, no. The general solution has to come from VSCode https://github.com/microsoft/vscode/issues/40233.
or a sequence of fallbacks that would be traversed in order to pick the default interpreter
We do have a sequence of fallbacks we follow to select the interpreter,
1. First check user settings.json If we have user settings, then always use that, do not proceed. 2. Check workspace virtual environments (pipenv, etc). If we have some, then use those as preferred workspace environments. 3. Check list of cached interpreters (previously cachced from all the rules). If we find a good one, use that as preferred global env. Provided its better than what we have already cached as globally preffered interpreter (globallyPreferredInterpreter). 4. Check current path. If we find a good one, use that as preferred global env. Provided its better than what we have already cached as globally preffered interpreter (globallyPreferredInterpreter). 5. Check windows registry. If we find a good one, use that as preferred global env. Provided its better than what we have already cached as globally preffered interpreter (globallyPreferredInterpreter). 6. Check the entire system. If we find a good one, use that as preferred global env. Provided its better than what we have already cached as globally preffered interpreter (globallyPreferredInterpreter).