Query for fresh workspace envs when autoselecting interpreters in a new workspace #17264
Conversation
karrtikr
force-pushed
the
optimizerefresh
branch
from
f377bd0 to
f7dc4ee
Compare
| ) { | ||
| super([...nonWorkspace, workspace]); | ||
| } | ||
|
|
||
| public iterEnvs(query?: PythonLocatorQuery): IPythonEnvsIterator<I> { |
There was a problem hiding this comment.
This adds support for only querying for workspace envs.
| /** | ||
| * Force an initial background refresh of the environments. | ||
| * | ||
| * Note API is ready to be queried only after a refresh has been triggered, and extension activation is blocked on API. So, |
There was a problem hiding this comment.
Various stuff like autoselection, jupyter integration requires the API, so it needs to be ready.
| */ | ||
| includeNonRooted?: boolean; |
There was a problem hiding this comment.
This changes the behavior to include non workspace envs by default.
karrtikr
changed the title
| * * If discovery was never triggered, we need to block extension activation on the refresh trigger. | ||
| * * If discovery was already triggered, there's no need to block extension activation on discovery. | ||
| */ | ||
| const wasTriggered = getGlobalStorage<boolean>(ext.context, 'PYTHON_WAS_DISCOVERY_TRIGGERED', false); |
There was a problem hiding this comment.
Just to confirm, this checks if discovery was ever triggered, not just for this session?
Does this mean that the extension activation will block on discovery for all users once when this PR lands, even though they might have already discovered interpreters before?
There was a problem hiding this comment.
Just to confirm, this checks if discovery was ever triggered, not just for this session?
Yep, that is correct.
Does this mean that the extension activation will block on discovery for all users once when this PR lands, even though they might have already discovered interpreters before?
No, quite the opposite actually. If they have already discovered interpreters, extension activation will not block on discovery.
We only intend to block on triggering discovery the first time when extension loads.
There was a problem hiding this comment.
The PYTHON_WAS_DISCOVERY_TRIGGERED key does not exist at the moment, so as soon as this PR gets merged the code will go through the condition on L.74-77 and wait on the api.triggerRefresh() part for everyone the first time they launch the extension, even users who have used the extension before and may have triggered discovery before.
Do we have any existing flags to see if any interpreters have ever been discovered?
There was a problem hiding this comment.
Ah, I see what you mean. We do have existing flags we can check but the one-time cost should be fine here, as this was always the behavior.
Closes https://github.com/microsoft/vscode-python-internalbacklog/issues/383