-
-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when trying to detect environment #1984
Comments
Generally I don't think Jedi is doing something wrong here.
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.
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?
As I wrote above, that is already there if you want it, it's called |
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 |
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?
No worries. |
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. |
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... |
Any updates here @karthiknadig ? I have this issue in VS code with python3.13 installed through brew together with other versions (3.11 and 3.12). I came here from the linked issue that is now not possible to comment |
@pdonorio This is issue with certain types of environments where the paths don't match expectation. Can you create a new bug on the python extension so I can investigate. Closing this issue here since the original is also not a bug with Jedi, and the solution should go into https://github.com/pappasam/jedi-language-server |
Ref issue from VS Code python Extension: microsoft/vscode-python#21265
In python extension we started passing the path to selected python executable to Jedi. It seems like in some cases Jedi fails to get the version information with a strange error. Not sure if any recovery steps can be used. 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.The text was updated successfully, but these errors were encountered: