zed-industries
Downloading language server for ssh host is not supported yet
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
- Remote to a machine
- Try to open a Python file (or any other supported language)
- See that there's an error message: "failed to start [language server]: Downloading language server for ssh host is not supported yet"
So we know that zed can't download them on its own. That's okay. But can I download it manually or force zed (via an ssh terminal) to download it just like it would if it was being ran from that remote machine? I see that remote zed is just normal zed that feeds some information back to my local zed. And that means it should be generally capable of downloading language servers, right? Even if not, then maybe I can fully manually download the language server and put it in $HOME/.local/share/zed/languages?
Environment
Zed: v0.155.2 (Zed) OS: Linux Wayland ubuntu 24.04 Memory: 14.3 GiB Architecture: x86_64 GPU: AMD Radeon Graphics (RADV GFX1103_R1) || radv || Mesa 24.0.9-0ubuntu0.1
If applicable, add mockups / screenshots to help explain present your vision of the feature
Footnote
In https://github.com/zed-industries/zed/issues/5347, I've seen someone complain about not having their LSP run as fast on remote as it would on local, so going by that it seems that having an LSP on a remote machine is possible?
You can install LSPs system-wide through your package manager and the remote Zed should pick them up from your PATH on the remote automatically. That is, unless the LSP in question is written in node.js, which is special.
You can install LSPs system-wide through your package manager and the remote Zed should pick them up from your PATH on the remote automatically. That is, unless the LSP in question is written in node.js, which is special.
"Which is special" love that.
Gonna test this out and let you know if it works
Unfortunately I can't seem to find the setting to point zed to the correct language server directory (pyright got installed in /usr/local/bin/pyright, and zed still says it wants to download it but can't, it's on path but not seen by zed apparently), but going to try to make a symlink to zed's language server directory none the less
Yeah, even after linking pyright to $HOME/.local/share/zed/languages/pyright it wants to download it and won't start up the one its got/is installed system-wide
Also adding
"binary": {
"path": "/usr/local/bin/pyright",
"args": []
},
to settings.json/lsp/pyright (btw, there should be a paragraph in general lsp documentation saying that this is possible, that code snippet is only shown in the rust section of the language servers zed doc) didn't change anything, as zed still tries to download pyright, and errors out on saying it can't do that on remote.
You can install LSPs system-wide through your package manager and the remote Zed should pick them up from your PATH on the remote automatically.
Hi, I am using Zed remote for Rust development, and I have rust-analyzer installed, but Zed won't pick it up:
Remote machine env:
$ uname -a
Linux fedora 6.10.9-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Sep 9 02:28:01 UTC 2024 x86_64 GNU/Linux
$ which rust-analyzer
~/.cargo/bin/rust-analyzer
$ zed --version
Zed 0.155.2 – /home/steve/.local/zed.app/libexec/zed-editor
Local machine env:
$ sw_vers
ProductName: macOS
ProductVersion: 15.0.1
BuildVersion: 24A348
$ uname -a
Darwin Steves-MacBook-Air.local 24.0.0 Darwin Kernel Version 24.0.0: Tue Sep 24 23:36:26 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T8103 arm64
$ zed --version
Zed 0.152.4 – /Applications/Zed.app
Do you have an explicit path for rust-analyzer configured on the local machine? I had to remove the path from my clangd config on the client in order to make the remote clangd work due to #18618 .
Do you have an explicit path for the rust-analyzer configured on the local machine?
Hi, thanks for the reply. I didn't configure the path to RA on my local machine, IIRC, Zed automatically downloaded RA and used it, the RA installed by me remains untouched.
btw, there should be a paragraph in general lsp documentation saying that this is possible, that code snippet is only shown in the rust section of the language servers zed doc
The reason it's not mentioned in the pyright section of the docs is probably because it's not supported for pyright. It's unfortunately not a setting that is universally available for all LSPs.
IIRC, Zed automatically downloaded RA and used it, the RA installed by me remains untouched.
You could try adding something like this to your config on the local machine
"lsp": {
"rust-analyzer": {
"binary": {
}
}
}
That's essentially what I have for clangd. Or you can simply wait for the remote LSP situation to get fixed properly.
Pyright is unfortunately one of the aforementioned node.js cases.
So it's not supported at all? Or just requires extra work to set up?
I see, how about taplo? I think I managed to get rust-analyzer to fire up, but now I get an error about taplo, and still it doesn't seem like r-a is giving any signs of life
I added this to both my local settings.json, and the settings.json on the remote machine (both executables exist, are on path, and can be used by the current user, the locations are the same on both the remote and local machine):
"lsp": {
"rust-analyzer": {
"binary": {
"path": "$HOME/.cargo/bin/rust-analyzer"
}
},
"taplo": {
"binary": {
"path": "/usr/local/bin/taplo"
}
}
},
Yeah, I did not get those two to show up in some cursory testing either :( Guess we'll just have to wait for SSH remoting to get fleshed out more.
I got the new update and tried it, but now there's just no error at all, and LSP stuff still doesn't show up. I removed my custom configs too. The patch notes even explicitly mention pyright too.
This should be fixed by v0.157 preview (for builtin languages - extensions are not yet supported).
I tried:
$ brew info zed
==> zed: 0.157.5 (auto_updates)
https://zed.dev/
Installed
/opt/homebrew/Caskroom/zed/0.157.5 (186.8MB)
Installed using the formulae.brew.sh API on 2024-10-16 at 14:59:15
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/z/zed.rb
==> Name
Zed
==> Description
Multiplayer code editor
==> Artifacts
Zed.app (App)
/Applications/Zed.app/Contents/MacOS/cli -> zed (Binary)
==> Analytics
install: 5,260 (30 days), 19,052 (90 days), 61,896 (365 days)
$ brew info zed@preview
==> zed@preview: 0.158.1 (auto_updates)
https://zed.dev/
Installed
/opt/homebrew/Caskroom/zed@preview/0.158.1 (190.0MB)
Installed using the formulae.brew.sh API on 2024-10-17 at 10:16:24
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/z/[email protected]
==> Name
Zed Preview
==> Description
Multiplayer code editor
==> Artifacts
Zed Preview.app (App)
/Applications/Zed Preview.app/Contents/MacOS/cli -> zed-preview (Binary)
==> Analytics
install: 273 (30 days), 1,114 (90 days), 1,871 (365 days)
And it seems that both won't work for Rust. 👀
@SteveLauC Are you using the new remoting?
Hi, I just upgraded to the lastest version, are there any extra components I need to install or upgrade?
I upgraded zed stable to 0.158.2, and it does not work. Manually restarting the lsp from the cmd prompt does nothing, opening the lsp log gives me an empty file
Extensions should hopefully land in 0.162, but it should already work for builtin languages.
Which language server are you expecting to run, and is there anything in the Zed log (cmd-shift-p Zed Log) that might help us debug?
Which language server are you expecting to run
Rust-analyzer
is there anything in the Zed log (cmd-shift-p Zed Log) that might help us debug?
It simply says: failed to spawn the LSP process
2024-11-06T10:04:20.132619+08:00 [INFO] ========== starting zed ==========
2024-11-06T10:04:20.136123+08:00 [INFO] Opening main db
2024-11-06T10:04:20.137986+08:00 [INFO] Opening main db
2024-11-06T10:04:20.1661+08:00 [INFO] Using git binary path: Some("/Applications/Zed Preview.app/Contents/MacOS/git")
2024-11-06T10:04:20.372416+08:00 [INFO] set environment variables from shell
2024-11-06T10:04:20.412963+08:00 [INFO] no tokio runtime found, creating one for Reqwest...
2024-11-06T10:04:20.433805+08:00 [INFO] initializing context server client
2024-11-06T10:04:20.433926+08:00 [INFO] Registering built-in prompt template: content_prompt
2024-11-06T10:04:20.434268+08:00 [INFO] Registering built-in prompt template: edit_workflow
2024-11-06T10:04:20.434424+08:00 [INFO] Registering built-in prompt template: project_slash_command
2024-11-06T10:04:20.43451+08:00 [INFO] Registering built-in prompt template: terminal_assistant_prompt
2024-11-06T10:04:20.434689+08:00 [INFO] No prompt template overrides directory found at /Users/steve/.config/zed/prompt_overrides. Using built-in prompts.
2024-11-06T10:04:20.435281+08:00 [INFO] extensions updated. loading 2, reloading 0, unloading 0
2024-11-06T10:04:20.487238+08:00 [INFO] Opening main db
2024-11-06T10:04:20.53659+08:00 [INFO] set status on client 0: Authenticating
2024-11-06T10:04:20.543828+08:00 [INFO] set status on client 60007: Connecting
2024-11-06T10:04:21.226704+08:00 [INFO] connected to rpc endpoint https://collab.zed.dev/rpc
2024-11-06T10:04:22.20523+08:00 [INFO] add connection to peer
2024-11-06T10:04:22.205561+08:00 [INFO] add_connection;
2024-11-06T10:04:22.205818+08:00 [INFO] waiting for server hello
2024-11-06T10:04:22.217094+08:00 [INFO] got server hello
2024-11-06T10:04:22.217442+08:00 [INFO] set status to connected (connection id: ConnectionId { owner_id: 0, id: 0 }, peer id: PeerId { owner_id: 606, id: 4902066 })
2024-11-06T10:04:22.217936+08:00 [INFO] set status on client 60007: Connected { peer_id: PeerId { owner_id: 606, id: 4902066 }, connection_id: ConnectionId { owner_id: 0, id: 0 } }
2024-11-06T10:04:22.982109+08:00 [INFO] remote development server present and matching client version
2024-11-06T10:04:23.905338+08:00 [ERROR] client:unhandled ssh message name:UpdateProject
2024-11-06T10:04:23.947571+08:00 [INFO] Opening main db
2024-11-06T10:04:23.957735+08:00 [INFO] Opening main db
2024-11-06T10:04:29.91981+08:00 [ERROR] (remote server) Failed to start language server "rust-analyzer": failed to spawn command. path: "/home/steve/.local/share/zed/languages/rust-analyzer/rust-analyzer-2024-11-04", working directory: "/home/steve/Documents/workspace/rust", args: []
2024-11-06T10:04:29.92015+08:00 [ERROR] (remote server) server stderr: ""
2024-11-06T10:05:01.949896+08:00 [ERROR] (remote server) Failed to start language server "rust-analyzer": failed to spawn command. path: "/home/steve/.local/share/zed/languages/rust-analyzer/rust-analyzer-2024-11-04", working directory: "/home/steve/Documents/workspace/rust", args: []
2024-11-06T10:05:01.95018+08:00 [ERROR] (remote server) server stderr: ""
Very odd.
If you manually run /home/steve/.local/share/zed/languages/rust-analyzer/rust-analyzer-2024-11-04, does it work?
If you have time, I'd love to debug this with you, can you send a time that works to [email protected] (I'm in US Mountain Time).
If you manually run /home/steve/.local/share/zed/languages/rust-analyzer/rust-analyzer-2024-11-04, does it work?
Things become interesting now. This binary does not have the execution permission, and after doing chmod +x binary, running it simply segfaults:
$ l
Permissions Links Size User Group Date Modified Name
.rw-r--r--@ 1 20M steve steve 6 Nov 10:04 rust-analyzer-2024-11-04
$ chomd +x rust-analyzer-2024-11-04
$ l
Permissions Links Size User Group Date Modified Name
.rwxr-xr-x@ 1 20M steve steve 6 Nov 10:04 rust-analyzer-2024-11-04
$ ./rust-analyzer-2024-11-04 --version
[1] 1520934 segmentation fault ./rust-analyzer-2024-11-04 --version
After replacing the RA binary with a working one, it works!
A more robust solution would be to install rust-analyzer in your PATH on the server I think? Presumably you have rustup installed there already so you can do rustup component add rust-analyzer to get the right version of r-a for your project-specific toolchain. (Also maybe zed should try invoking rustup from PATH first before downloading the binary directly? That would be much more robust on e.g. NixOS where rustup has been modified to automatically patch downloaded binaries so they work)
Thanks for figuring it out!
I've fixed a couple of other bugs recently where we download directly in place which causes exactly this if your download is interrupted. Let me see if we can update the way we install language servers to not have this problem too.
A more robust solution would be to install rust-analyzer in your PATH on the server I think
Actually, I did have RA installed via rustup, and when I dug into the issue, I thought it caused Zed to fail, so I uninstalled it.
As of recent Zeds we should prefer the rust-analyzer you have in the path.
That said, we found that (at least for the Zed team) the rust-analyzer installed by rustup seems to often not actually work, so we may end installing our own anyway https://github.com/zed-industries/zed/pull/17951/files
That said, we found that (at least for the Zed team) the rust-analyzer installed by rustup seems to often not actually work
I've noticed the same, usually the error I get is something like 'rust-analyzer' is not installed for the toolchain '1.81-x86_64-unknown-linux-gnu' and the fix is to run rustup component add rust-analyzer or rustup update. In the cases I've seen the explanation turns out to be somewhat surprising, although simple:
$ file /usr/bin/rust-analyzer
/usr/bin/rust-analyzer: symbolic link to rustup
And it would seem that when the toolchain version of the project one tries to start rust-analyzer for is updated, it will fail if rust-analyzer hasn't been installed for that toolchain version yet. Zed frequently bumps the toolchain version in rust-toolchain.toml so it's not surprising that you'd run into this frequently. I believe the idea of rust-analyzer being a symlink to rustup is that the same rust-analyzer invocation can automatically pick the right version of the toolchain for any project it is launched in (which has been done via rustup for ages), but the wrapper that chooses the version does not automatically install it if it's missing.
So if Zed redownloads the whole rustup & rust toolchain, chances are it will either break the user's rust installation or get overwritten by the system rustup installation the next time the user runs a cargo command from outside Zed. (and on NixOS it of course won't work to begin with because the NixOS rustup is modified to patch the downloaded binaries on the fly so they work with the nix-provided glibc) Hence why I suggested that Zed should try going through the system rustup if that exists.