Error when trying to detect environment about jedi HOT 5 OPEN

Generally I don't think Jedi is doing something wrong here.

It seems like in some cases Jedi fails to get the version information with a strange error.

This is unfortunately not a strange error, but a fundamental issue with the executable. When started in a subprocess, the executable just dies.

The issue to me is very unclear here. It feels like a broken Python. Or something specific to Windows where it's not possible to start links as a subprocess or whatever. I have really no Windows specific knowledge.

Not sure if any recovery steps can be used.

There are currently no recovery steps, because this was never an issue as far as I know. I haven't had any reports (other than the bugs we fixed).

It would be possible that you guys catch this specific exception and just pass an InterpreterEnvironment as a fallback, which would mean that Jedi would run within the same Python that you start it. Unless it happens to a lot of your users I probably wouldn't do that, because that just hides the actual issues (which we do not understand yet). How many issues like that have you had?

One enhancement I think could be: if the sys.executable path is the same as the environment path, then probably there is no need to run this to get more info.

As I wrote above, that is already there if you want it, it's called InterpreterEnvironment.

from jedi.

I think we should be able to do what you suggest as a fallback. Also, sorry for assuming this was an error in Jedi.

This is likely a suggestion to jedi-language-server package, as that is the one sitting between VS Code and Jedi. I will raise an issue there with details.

from jedi.

I'm not sure that's a good idea, just because we don't know yet why this is happening. How often does this happen to your users?

Also, sorry for assuming this was an error in Jedi.

No worries.

from jedi.

This is the first time I have seen this being reported. This started happening after we started passing the path to environment dir or the python binary in the environment. This was part of fix to improve virtual environment experience with jedi.

from jedi.

I just feel like this is something that a user wants to know. So if you add a fallback, it might also generate github issues about sys.paths that are not found at the right places and at that point the fallback just bites you.

So I feel like this is really an issue of the underlying system of the original reporter. However a fallback could at least provide partial support for completions...

from jedi.