Provide a way to enter path to an interpreter without triggering interpreter discovery

[EntilZha]

The primary requested feature is the ability to customize and specifically limit where the python extension looks for virtual environments (https://code.visualstudio.com/docs/python/environments#_where-the-extension-looks-for-environments). The main reason for this is that it seems like in multi-user shared environments with many virtual environments, the remote extension doesn't seem to work correctly and floods network IO (bug report: #10866).

We haven't been able to determine a root cause for certain though and its difficult since as far as we know there isn't enough instrumentation/config options for restricting virtual environments search paths (only adding them).

[karthiknadig]

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

[luabud]

We're changing the scope of this issue because the behaviour of the extension could be affected if, for example, a selected interpreter that is located in a folder that is ignored in the discovery process (e.g. the extension could fail to recognize what is the selected interpreter and therefore fail to execute tools).

From what I understand, the underlying issue is the extension gets blocked when it's attempting to discover interpreters on a machine that have many environments available. So instead what we can do is to offer a way to enter a path to an interpreter without making environment discovery required.

But of course, if you don't think this alternative would actually solve the problem we're happy to discuss it further 😊

[hypostulate]

Luciana Abud (@luabud) Yes, that would both provide a workaround for this issue and also alleviate some headache around conda environment discovery (forced reload of the window following environment creation).

[EntilZha]

Agreed, it seems like that would both fix the issue and also prevent forced reloads.

That said though, I'm not sure that the failure to find the selected interpreter would be an issue preventing improved configuration on interpreter discovery (in addition to being able to give the path). For example, I've done this before:

• Use VS Code for a certain project, with a certain interpreter
• Stop working on project for a while, ended up deleting the environment
• Return to VS Code, it fails to find interpreter so no tools load, but its an easy fix to select a new interpreter (there is a yellow danger symbol where python version would be at bottom).

In the case of changing discovery path, it would be equivalent to deleting the environment which currently doesn't cause too much issue. I haven't looked at how environments are discovered, but is it based on a set of paths to explore from (so easy to configure) or is it dynamically done (so harder to configure)?

[hypostulate]

Pedro Rodriguez (@EntilZha) I believe interpreter discovery for conda environments is done by calling conda env list and then subsequently parsing out some details for each environment. I think that is why it is harder to configure, although perhaps injecting a path-filtering layer between the conda env list call and the environment detail retrieval could work as a solution.

[EntilZha]

That makes sense, so i guess the question then is if the call to conda env list is the issue blocking the extension. If so, then a post filtering step probably wouldn't help, so a manual config of the interpreter path (while disabling discovery) might work better.

In either case, I'd love for manual configuration from a specific path, I've run into the use case of creating a new poetry/conda env and needing to restart VS Code to get it picked up (in poetry's case, restart with code . after poetry shell). It also provides at least one definitive fix to the issue.