-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Does not resolve pyproject.toml
(using WSL2)
#93
Comments
pyproject.toml
(using WSL2)
I'll look into this by the end of this week. Thank you both for reporting the problems. It is really nice to know that something I maintain have such dedicated users. So nice, in fact, that the debugging nightmares don't seem too bad after all. |
@InSyncWithFoo -- Honestly, your plugin is the last hope Intellij has of keeping me as a user of pycharm at all. Their built in type checking/inference is hopeless. |
Currently, only the Native LSP client supports WSL. This is the recommended mode if you are on PyCharm Professional. The cause of the bug is a failed check for the specified executable's existence. Given a path of the form I couldn't, for the life of me, create a proper Poetry project, but I suppose that is unimportant. Please install the build manually (see installation guide here) and let me know if it works for you. Small note: This mode (and LSP4IJ) doesn't respect the configuration file field at all (there are reasons for that), only |
@InSyncWithFoo When opening files, I see error notifications like this: Here are screenshots of what I think are the relevant configurations:
In pyproject.toml Super simple test file that has several typing errors |
@TimChild What do you see in the logs? You might have to enable language server logging to make the most out of it. The entries containing If you don't want to post your logs publicly, you can send an email to |
@InSyncWithFoo Just sent you and email with some logs. |
@TimChild It seems that the server was hanging ("No response from the server in 10000ms"). I will need everything you can send me; please set "Log level" to "Trace" so that we know what Pyright has to say as well. I also found these issues over @microsoft/pylance-releases:
This means either Pyright itself is not handling the paths correctly, or I'm sending it malformed paths. |
Editied this comment because I didn't realise I was relpying to a github email...
Just sent an email to your gmail address with the log file at trace level from IDE startup to seeing the error notification in the IDE.
|
@TimChild I think I know what the culprit is. You seem to have the LSP4IJ plugin installed (it used to be a required dependency before 0.7.0, but no longer). Try disabling or uninstalling it, then restart and try again. LSP4IJ and the native client are incompatible with each other, since they share a dependency that (due to Java's limitation or whatever) can only be loaded once. This is what causing the weird errors that would otherwise be undebuggable ("class |
@InSyncWithFoo Removing LSP4IJ seems to have fixed the error notification, but I'm still not seeing any squiggles... I noticed that the inspections for pyright got disabled at some point (maybe when removing LSP4IJ?), but re-enabling didn't make any difference... I've emailed you a new set of logs. Thanks a lot for all this work you're doing! |
The problems are quite evident:
Regarding the first problem, this is probably because your As for the second, I could only guess that the WSL distribution somehow wasn't detected properly. Please try out the new build at #96, which falls back to detecting the distribution from the project's UNC path. |
@InSyncWithFoo -- Ah yes, I do have my pyproject.toml file in a different folder.. Using And yes, I see now that the logs show that pyright is doing the right thing. Unfortunately, I'm still seeing the error for
That's after uninstalling the plugin and installing the one at #96 I assume that part works find for you using WSL2? Everything about the path looks fine to me assuming that the I don't see anything in the log lines following that to suggest that any other filepaths are being looked for btw (if that's related to what you just implemented), it just goes onto the next pair of |
Ok, just read into file URIs a little.. I see that So I guess from there, pycharm needs to somehow know that the path refers to a file within wsl2... I don't know kotlin, so struggling to read through your changes... I just noticed you added some logging though, so here is what I see for that in the logs:
|
I'm also running PyCharm on the Windows side. This part is responsible for converting a LSP file URI to a Windows path, which PyCharm can use to search for the file in its virtual file system. This conversion is necessary because both the project and Pyright itself live in Linux realm. The file URI represents a Linux path; it doesn't know anything about Windows. To convert that to an UNC path, it is necessary to know the distribution. private fun findFileByUri(fileUri: URI): VirtualFile? {
val virtualFileUri = when {
wslDistribution == null || fileUri.pathIsAbsoluteDos -> fileUri
else -> Path.of(wslDistribution!!.getWindowsPath(fileUri.path)).toUri()
}
return super.findFileByUri(virtualFileUri.toString())
}
Assuming all of that are correct, this URI is then passed to the default implementation by JetBrains, which eventually concluded it leads to nowhere. What that does boils down to: // .path: //wsl$/Ubuntu/home/tim/../file.py
LocalFileSystem.getInstance().findFileByPath(URI(virtualFileUri.toString()).path) The latest commit I just pushed should help us confirm this, but if even this call is unable to find your file, then I'm not sure what else I can do. |
Well, here's the new logs:
Resolved virtual file URI looks good... But still not working. Anything there enlightening to you? |
@TimChild There is, actually. The virtual file URI has |
@InSyncWithFoo
In Weird that my wsl2 behaviour is different to yours, but great that you managed to get the command line mode working. Unfortunately, I now have to decide between having pyright, or having my ruff formatting run correctly... Thanks for all the help! FYI my wsl2 ubuntu version is:
Is that the same as you? |
Might also be related to this... I'm now wondering if there is a common theme with some of the other issues I have with Pycharm (like the debugger not always respecting breakpoints). |
(I'm on Windows 10 and Ubuntu 24.04.) I'm glad to hear you got it working, and I'm sorry for not being able to resolve this more cleanly. I'll get the PR merged after a little refactoring. Thanks again for being such an awesome user! |
@InSyncWithFoo do you know how LSP4IJ should be improved to support ws2l like lsp native does? Please create an issue in lsp4ij repo to explains what you need. My first impression is that you need a new LSP api but perhaps I am wrong? |
What happened?
Pyright runs, doesn't produce any obvious errors (is there a log somewhere that I can check for more details?) but doesn't seem to be using the
pyproject.toml
settings that are picked up when runningpyright
from wsl2 terminal directly.I went down a whole rabbit whole thinking it was just a filename conversion issue related to wsl2, but I'm not sure now...
@InSyncWithFoo I'm hoping that you'll just be able to spot obvious to you given your recent work here where you "overcame a nightmare".
Steps to reproduce
Repository and poetry env live in WSL2, pycharm is being run from windows. Pyright is installed in poetry env.
First thing I noticed was that packages installed in the poetry env weren't being recognized, but further testing revealed that the whole pyproject.toml settings are being ignored (i.e. setting
reportXXX = false
in[tool.pyright]
has no effect on warnings shown.Setup and things I tried:
Also tried setting the
configuration file
to thepyroject.toml
or apyrightconfig.json
file but whatever I selected wouldn't save (maybe that is actually a bug?). I don't think it should be necessary though since thepyproject.toml
should have been detected automatically by pyright (as it was when running from wsl terminal).In
pyproject.toml
I don't think the
language server
part does anything withCommand line
mode selected (right?).Things I also tried:
LSP4IJ
mode with thewsl -e /....
and with just/home/...
and withC:\\...
(and pyright installed in windows), but either it would fail starting up, or I would get an error related to path starting with//
(which I think came from running pyright from cmd/powershell, and the filenames being passed as//wsl.localhost/...
)Native LSP client
mode with the different options above -- Seemed to ignore the settings, but errored becausezsh:1: command not found: C:\Users\...\pyright-langserver.exe
andCommand line: C:\Users\...\pyright-langserver.exe --stdio\nStdIO connection closed\nExit code: 127
Tried these things before I realised the pyproject.toml was not being used at all...
venvPath
-- tried starting with//wsl.localhost/Ubuntu/home/....
,//wsl$/Ubuntu/home/...
extraPaths
-- with path to thesite-packages
directly (similar path styles to above)All in vain...
Seems like the Native LSP client mode could work given than the first command tried to run from
zsh
, if only I could point that to the pyright in wsl instead of the windows path, but I couldn't figure out where to configure that.Or is there a better solution I am missing altogether?
System:
Win 11
PyCharm 2024.3 (Professional Edition)
Build #PY-243.21565.199, built on November 12, 2024
pyright 1.1.389 (both in windows and poetry env)
Sorry to bring up PyCharm/WSL nightmare stuff again!
Relevant log output or stack trace
Operating system
Windows
The text was updated successfully, but these errors were encountered: