-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
extraPaths in language server no longer work on pyright >= 1.1.340 #7016
Comments
@rchiodo, this looks like fallout from the recent URI changes. Do you want to take this bug? |
Sure. @FindDefinition what's your pyrightconfig.json look like? I cannot reproduce this in VS code using these settings: Can you set this in your pyrightconfig.json and upload the logs then: "verboseOutput": true The server output is just showing the same thing as the screenshots do - that pyright can't find the imports. With trace logging turned on, we should log a lot more messages. Specifically, there should be something that has the paths we searched for the failed import. For example without the
|
This one in particular should show what we searched for in your extra paths:
(I had this hardcoded to the wrong path initiallly) |
@rchiodo I can't reproduce this problem with pyright config (with only extraPaths) and command line interface. when I enable
pyright 1.1.339:
You can see the language server config sent by language client, may be there is some problem between language server and pyright core? |
VS code is using the pyright server too and doesn't have this problem. Well at least for me. Can you try VS code to see if you can reproduce your issue? Otherwise, I'd need some way to reproduce it locally. |
@rchiodo you can start a pyright language server and send jsonrpc messages above to reproduce. |
Thanks I'll try that. I'm going to hazard a guess and say I broke rooted paths somehow. At least that looks like one difference between my configuration and yours. |
I have a similar problem. I'm using The version I was using earlier was v1.1.326 and it didn't have this issue. |
Found the root cause. Internally we're trying to combine the extra paths with the workspace URI. In the test code provided, there is no workspace URI and combining an empty URI with anything (currently) returns empty. So, the extraPaths are essentially nulled out. A workaround would be to pass a workspace folder message. Like so:
That allows the extraPaths to be combined correctly (even if the combination just returns the original extra path). For example, I now get this in my extraPaths:
|
When will the next version be released? |
I typically publish a new version of pyright about once a week — when there are enough fixes or features to justify a new release. A new version of pylance is released once a month. |
This is addressed in pyright 1.1.348, which was just published. It will also be included in a future release of pylance. |
@erictraut @rchiodo this problem comes back in pyright >= 1.1.356, the uri becomes empty in language server output. |
@FindDefinition let me take a look |
@FindDefinition can you provide logs (https://github.com/microsoft/pylance-release/wiki/Collecting-data-for-an-investigation.#collecting-trace-logs) ? I couldn't repro it with |
Describe the bug
I'm using pyright as language server via a websocket server and pyright server run in
--stdio
mode. recently I found that my dev project (installed viapip install -e .
) can't be resolved by pyright langserver. previously I useextraPaths
to tell pyright check my dev project and it works well in pyright <= 1.1.339.packages in standard python directory (miniconda3) have no problem.
I test some pyright versions by binary search and get following result:
version <= 1.1.339: works
version == 1.1.340: hang
version >= 1.1.341: not working
Code or Screenshots
I can provide language server input and output jsonrpc messages:
1.1.347:
1.1.339:
error screen shot:
VS Code extension or command-line
I'm using monaco, not vscode.
The text was updated successfully, but these errors were encountered: