Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to disable the new DeprecatePythonPath feature #17693

Closed
jan11011977 opened this issue Oct 11, 2021 · 19 comments · Fixed by #18256
Closed

Add the ability to disable the new DeprecatePythonPath feature #17693

jan11011977 opened this issue Oct 11, 2021 · 19 comments · Fixed by #18256
Assignees
Labels
area-editor-* User-facing catch-all feature-request Request for new features or functionality verified Verification succeeded
Milestone

Comments

@jan11011977
Copy link

jan11011977 commented Oct 11, 2021

Could we please add an option to go back to the old "pythonPath" behaviour.

Selecting the python interpreter using the "python.pythonPath" setting has been working great for us. We check our Python environments into source control, along with the vscode settings and our code. Our engineers don't have to worry about anything; they just open the vscode workspace and everything works.

With this new "defaultPythonPath" system, a lot of our engineers are ending up with the wrong interpreter (it doesn't help that when this feature was rolled out, VSCode would prompt people to change the interpreter and then highlight a "recommended" interpreter which was the wrong one).
Once they have selected the wrong interpreter, they are then stuck with a broken VSCode. For most of our engineers, Python isn't their primary language, so they have no idea what's wrong. They will just suffer with broken Intellisense and spurious linting errors, and assume it's meant to be like that.

If I'm being honest, this new feature is a nightmare for us. We are desperate to go back to the old system where everything is centrally controlled and just works.

@jan11011977 jan11011977 added triage-needed Needs assignment to the proper sub-team feature-request Request for new features or functionality labels Oct 11, 2021
@karthiknadig karthiknadig added triage area-editor-* User-facing catch-all and removed triage-needed Needs assignment to the proper sub-team labels Oct 11, 2021
@karrtikr karrtikr removed their assignment Oct 11, 2021
@luabud
Copy link
Member

luabud commented Oct 12, 2021

Hi @jan11011977, thanks for providing feedback. The new setting should have the same behavior as python.pythonPath did in terms of selecting the right interpreter when the workspace loads.

For context, the Python extension will only prompt to select an interpreter if it doesn't recognize the one defined by python.defaultInterpreterPath (and the same happens for python.pythonPath). So when you say the following, it sounds to me that what you're experiencing is actually a bug:

With this new "defaultPythonPath" system, a lot of our engineers are ending up with the wrong interpreter (it doesn't help that when this feature was rolled out, VSCode would prompt people to change the interpreter and then highlight a "recommended" interpreter which was the wrong one).

Are you able to share some steps so we can reproduce the issue?

@karrtikr karrtikr added the info-needed Issue requires more information from poster label Oct 25, 2021
@jan11011977
Copy link
Author

Hi @luabud, sorry for the late reply.

My understanding is that python.defaultInterpreterPath is ignored if the user has already selected a valid Python interpreter. The trouble comes if the user has selected the wrong Python interpreter. We check a full Python install into source control, and we'd like VSCode to use that. however if a user selected a different (valid) interpreter for example one off their own machine, there is no way for us to correct that problem automatically.

Please correct me if I have misunderstood how this works.

@luabud
Copy link
Member

luabud commented Dec 29, 2021

Apologies for the delay in my response!

Your understanding is correct. Our recommendation in this case is to not have the Python path checked into source control (i.e. remove the python.defaultInterpreterPath entry from .vscode/settings.json) for this not to happen, as rarely ever the path to the interpreter will be the same across different machines.

However I will keep this issue open so I can talk to the team about it and make a decision.

@luabud luabud added needs decision and removed info-needed Issue requires more information from poster triage labels Dec 29, 2021
@luabud luabud removed their assignment Dec 29, 2021
@jan11011977
Copy link
Author

Thank you!

As I mentioned, we check a python interpreter into source control. So the location is always the same (relative to the vscode workspace).

We have a workspace with 7 different directories in, some of which require a different python interpreter than others.
This means every user has to click on “select interpreter”, then choose the relevant directory and select the right interpreter for that directory. And they have to do this for each directory, so seven(!) times.

There is no way to view what interpreter each directory is currently set to, to check for mistakes. This makes it impossible to diagnose issues.

Really this workflow has gone from brilliant (specify the python path in the settings), to completely unusable (manually have every user set all seven python paths).
From reading other threads we are not the only ones having this problem.

I hope there is something you can do about this issue.

@karrtikr
Copy link

karrtikr commented Jan 6, 2022

We have a workspace with 7 different directories in, some of which require a different python interpreter than others.
This means every user has to click on “select interpreter”, then choose the relevant directory and select the right interpreter for that directory. And they have to do this for each directory, so seven(!) times.

Sorry I do not understand this particular issue, given python.defaultInterpreterPath is checked into source control, you can simply specify the particular setting for each directory (which is opened as a workspace folder), so users don't have to select it themselves. So users would automatically get the correct interpreter to start with, can you clarify?

The behavior of the new setting is the same as the old one until an interpreter is manually changed for the workspace folder by the user using the "Select Interpreter" prompt. (docs)

image

however if a user selected a different (valid) interpreter for example one off their own machine, there is no way for us to correct that problem automatically.
There is no way to view what interpreter each directory is currently set to, to check for mistakes. This makes it impossible to diagnose issues.

Regarding the diagnosing issue which comes when a user decides to change an interpreter themselves, we actually log the interpreter in the Python output channel so you can potentially check there. We also expose an API using which you can detect this automatically.

@jan11011977
Copy link
Author

jan11011977 commented Jan 6, 2022 via email

@elazarcoh
Copy link

@jan11011977 see if this workaround helps in your case:

  1. Install this extension: usernamehw.commands.
  2. Go to the new Commands view.
  3. Add a command for python.clearWorkspaceInterpreter.
  4. Right click on the command: Toggle Status Bar Item.
  5. Right click on the command: Reveal in settings.json.
  6. Edit the statusBar.text to your liking.

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

Thanks for the quick reply.

What I would ideally like is a button in Visual Studio code that resets all
the python interpreter settings back to the default (inherited from the
defaultInterpreterPath). That would be a big help.

The docs I mentioned earlier (doc) does mention a command Python: Clear Workspace Interpreter Setting which does this. I have also created #18255 to increase discoverability of this feature.

Now I try to change the setting and reload the workspace,
but the incorrect setting has already been "fixed". Or maybe it hasn't

It doesn't get fixed as long as you don't use the "Select Interpreter" prompt UI. If you directly change the value of the setting, it should get picked up.

It's hard to say because there is no UI that shows me what is happening.

There're actually two UIs which shows the selected interpreter. One is here:

image

and other is the Python Output Channel like mentioned before. (Although I agree currently there isn't a single UI to show all selected interpreter for all directories/workspace folders)

What would also be great is if we could see which python interpreter was
selected for each directory in a single place. For example, if you click
the 'select interpreter' button it brings up a menu asking you to select
which directory to choose the interpreter for. If in this menu it could
show the currently selected interpreter in small letters underneath each
menu option that would be a game changer.

Sure, we can do that as part of this issue.

Overall I understand the confusion, please give the TLDR section a fresh read, and let me know if it makes sense.

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

There you go:

image

@jan11011977
Copy link
Author

Thank you this is really helpful.

In the TL;DR it states: the extension will read the value when loading a project **for the first time.**. I took this to mean that it only looks at the defaultInterpreterPath once (the first time someone loads the workspace) and ignores that setting from then on.

But I now see that it will continue to use the defaultInterpreterPath, unless the user explicitly chooses a different interpreter. Thank you for pointing that out.

Using the 'Clear Interpreter Command' I managed to now get this working the way I want, which is fantastic.

Showing the current interpreter path text in the select folder quickpick is also super helpful, thank you for adding that as well.

The only remaining thing that would really helpful is to have a single command that clears all the selected interpreters. Right now I would have to tell our developers to run the clear command on all 11 folders (plus the workspace).

If there was a single command to clear them all, I could then tell everyone "if you are having issues, please run this command and it will fix it".

Thank you for the help

@jan11011977
Copy link
Author

Ok actually I have one more suggestion related to the "No Python interpreter is selected" dialog (see image below). It would be very useful if the dialog told you which folder it's prompting you to select a Python interpreter for. This might be obvious if you only have one directory open, but if you have a dozen directories open it's hard to know which one it's complaining about.

image

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

Good to hear that most of your problems are solved and thanks for valuable feedback regarding doc.

Right now I would have to tell our developers to run the clear command on all 11 folders (plus the workspace).

There's currently a command called Python: Clear Internal Extension Cache which clears all the cache extension uses to store data across sessions. It'll clear settings and more, and essentially gives any user a fresh start.

If you still need it, I'll see if I can add an option in that command to clear settings of all workspaces.

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

Ok actually I have one more suggestion related to the "No Python interpreter is selected" dialog (see image below)

This is also a great suggestion, but seeing as it's unrelated to the issue in hand, can you create a new issue for this?

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

If there was a single command to clear them all, I could then tell everyone "if you are having issues, please run this command and it will fix it".

Working on adding a "Clear all" option in the 'Clear Interpreter Command':

image

@jan11011977
Copy link
Author

Fantastic! Thank you so much

@karrtikr
Copy link

karrtikr commented Jan 7, 2022

Created #17667 to track #17693 (comment).

@karrtikr karrtikr added the verification-needed Verification of issue is requested label Jan 7, 2022
@NorthIsUp
Copy link

rarely ever the path to the interpreter will be the same across different machines.

many large orgs use tooling to ensure consistent environments. not being able to check in tooling configs for vs-code will make it significantly harder for our devs to onboard.

supporting the common case of ~/.virtualenvs would be very helpful

@kariharju
Copy link

Pinging the API issue here as well (#16994)
..also trying to figure out if calling Python: Clear Workspace Interpreter Setting and then setting python.defaultInterpreterPath would be a way to get by this one.

@karrtikr
Copy link

That is correct.

@karrtikr karrtikr added verified Verification succeeded and removed verification-needed Verification of issue is requested labels Jan 26, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-editor-* User-facing catch-all feature-request Request for new features or functionality verified Verification succeeded
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants