You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need code in TS to resolve the version, env_path when they are empty. Current code is incorrect, it will replace all of the other information (eg Kind gets replaced)
Problems identified
Environments resolved in old code will end up overriding info resolved by Native Locator More
Native locator returns 100% of information 99% of the time.
In the case of Windows store we do not have the version information
While native locator is finding environments, its possible for old code path to resolve an enviornment (e.g. a global env selected as active env), then the old code could resolve this and by the time the old code gets the env info, the latest env info has been set in cache, However this gets overridden by the env info retrieved by old code path.
While this might sound ok, some of the information retrieved by old locators is incorrect, e.g. a conda enviornment will be detected as unknown, or global system env will be detected as unknown, other conda as something else...
I think the best way to address this is to have the native locator also resolve environments on demand (i.e. have native locator provide the ability to spawn and return the information).
Else all of the run commands, etc computed by native locator will end up getting overridden by the old locator resolver code.
(posix/windows): Pyenv-venv@DonJayamanne(posix/windows): activestateMisc
3attributes for Environment (exe, run command,activation command) @DonJayamanneEnsure resolvers accept data from native locators #23444
Kindgets replaced)Problems identified
More
Native locator returns 100% of information 99% of the time.
In the case of Windows store we do not have the version information
While native locator is finding environments, its possible for old code path to resolve an enviornment (e.g. a global env selected as active env), then the old code could resolve this and by the time the old code gets the env info, the latest env info has been set in cache, However this gets overridden by the env info retrieved by old code path.
While this might sound ok, some of the information retrieved by old locators is incorrect, e.g. a conda enviornment will be detected as unknown, or global system env will be detected as unknown, other conda as something else...
I think the best way to address this is to have the native locator also resolve environments on demand (i.e. have native locator provide the ability to spawn and return the information).
Else all of the run commands, etc computed by native locator will end up getting overridden by the old locator resolver code.