Interpreter discovery times out on first load

[mnoah1]

In our monorepo (which uses Python + Bazel), we have a setup where the very first python run in the repo can take longer to complete (there is some additional work like building generating dependencies and setting up the venv going on). As a result, the interpreter info script fails to complete in time on this initial run.

It appears there is a hard coded 15 seconds in place for this step - we would like to make this configurable so that it waits long enough for this to complete and users don't get an error in this scenario.

[karthiknadig]

Can you provide some details on the very first run of python? Is it that we select the venv the moment it gets created and then it fails? Can you provide details on the failure?

[mnoah1]

Can you provide some details on the very first run of python?

With Bazel, the first run also has to populate the Bazel cache (e.g. including downloading external dependencies and creating any generated files), then creates the venv and symlinks to the python interpreter inside the cache. After that python can actually run.

Can you provide details on the failure?

Once the run takes longer than the 15 second timeout (the line I edited in the PR mentioned above), the process gets killed and interpreter discovery fails or may search the system for other possible interpreters and select the wrong one. If it weren't for the timeout, it would succeed.

Given this, and the fact that this setup likely only affects a small subset of users, I suggest a configuration option that would allow this timeout to be extended if a repo's setup warrants it.

[karthiknadig]

Would it be enough if this timeout was set via an environment variable?

We are working on changing the python discovery process. Making it reliable and extensible. We would like to avoid adding any settings that we may need to take out as a part of the process. The work that we are doing would allow you to contribute a custom environment manager (creator, selector, etc), so you can control that experience.

[mnoah1]

Yes, that will work too. Do you just mean an environment variable via the extension's process.env?

[karthiknadig]

Yes. process.env.

[mnoah1]

Hi @karthiknadig - I went ahead and updated #24227 to support this. Can you take a look?