Support new Python Environments API when enabled

[Weidav]

The implementation adds support for the new Python Environments API when the setting "python.useEnvironmentsExtension" is enabled. Ensures that the basedpyright extension correctly reads the active Python environment, aligning its behavior with that of Pylance and addressing #1855.

The ms-python.vscode-python-envs API interfaces are defined to avoid importing the api and having it as a dependency. This would fail if the pyhton-envs extension is uninstalled and I think also when its deactivated.

I use some python-test-fixtures in my extension, which make it easier to manually (an also automatically) test the extension. It's basically some different typo of python projects whit different dependencies, so missing or failed imports are quickly identifiable. Are you interested to add them to your tests/repo?

[Weidav]

The implementation is finished, the tests don't cover this though, so manual testing is needed. I built the extension and tested it on my monorepo. So far so good.

I'll remove the draft-status once the question about the python-test-fixtures is clarified.

[DetachHead]

thanks! to answer your question, i'd be happy to add these fixtures but if we do, i'd prefer that we also add automated tests that use them. the vscode extension doesn't currently have any tests though and i'm not sure how easy it is to write tests for vscode extensions

[Weidav]

I have a little bit of experience in writing tests for extensions and can set them up, but I'm not deeply enough involved in basedpyright evaluate which tests make sense and which don't. In my experience LLMs can be very helpful to quickly write lots of tests, but often tend to overdo it and write to many of them. You would need to evaluate them and I fully understand if you don't want to review AI-written tests. So let me know what you prefer, I could only prepare the setup and add a test or two as a blueprint and let you write the rest of the tests, or I add the tests with the help of LLMs.

I think that is worth another Issue and a separate PR.
I'll remove the draft status here and open an Issue for the tests with a few more details.

[DetachHead]

i appreciate you asking first before throwing a bunch of AI generated code my way. in my experience, LLMs seem to be very bad at writing tests. the tests they write often don't actually test anything at all.

with that in mind, and considering that i've recently added a policy prohibiting AI generated code, i would much prefer this option:

I could only prepare the setup and add a test or two as a blueprint and let you write the rest of the tests

thanks

[Weidav]

I opened an issue and added the infos form your response to #1861. I'll have time to implement the test-setup mid-August.

So this PR is ready and can be reviewed :)

[Weidav]

I also fixed the error logging, that actually didnt work with the PythonEnvironmentApi

[Weidav]

I didn't format the code in my last commit, did so now, now the pipelines should pass.

[DetachHead]

we should only call installPythonPathChangedListener if it successfully gets the PythonEnvironmentApi object right, otherwise it would install 2 separtate listeners when it falls back to the old api?

Suggested change

	installPythonPathChangedListener(envsApi.onDidChangeEnvironment, scopeUri, postConfigChanged);
	const result = await getPythonPathFromEnvsApi(envsApi, log, scopeUri);
	if (result !== undefined) {
	return result;
	}
	log('Python Environments extension returned no interpreter, using classic API');
	const result = await getPythonPathFromEnvsApi(envsApi, log, scopeUri);
	if (result !== undefined) {
	installPythonPathChangedListener(envsApi.onDidChangeEnvironment, scopeUri, postConfigChanged);
	return result;
	}
	log('Python Environments extension returned no interpreter, using classic API');

[Weidav]

imho. it belongs before it gets the result.
getPythonPathFromEnvsApi() calls PythonEnvironmentApi.getEnvironment(), which can legitimately return undefinded when no env is currently selected in the Python-Envs extension.

The pythonPathChangedListenerMap will only register one listener.

[DetachHead]

but when getPythonPathFromEnvsApi returns undefined it falls back to the classic API, meaning the path changed listener for the new API will be registered even though it's actually using the old API. is that fine?

[DetachHead]

looks good, just that one thread left about the installPythonPathChangedListener that i still don't really understand

[DetachHead]

w/e i'll just merge this as is, seems to work fine

[Weidav]

Hi, sorry for the late response & thanks for the merge!

I don't know how to explain it better, but happy that it works!