Fix DAP binary resolution for remote worktrees - #94
Conversation
|
We require contributors to sign our Contributor License Agreement, and we don't have @TateWalker on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'. |
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
|
@MrSubidubi checking to see if anything on this needs changing |
This comment was marked as spam.
This comment was marked as spam.
MrSubidubi
left a comment
There was a problem hiding this comment.
I see the brief description above, but would you mind explaining how this prevents the auto-install and also on the $PATH-part? Does this happen because if we boot the remote server CLI, we do not load the full user path and hence need the which-API which does just that?
TateWalker
left a comment
There was a problem hiding this comment.
To clarify, I meant that when I open Zed, it auto-replaces my custom dart extension (this one) with the official one, rolling back my changes. I then have to uninstall and reinstall my dev extension to resume remote debugging work. That issue isn't related to this PR, just stating a separate concern.
On the $PATH question: yes, exactly. The remote server process may not load the full login shell environment, so $PATH can be incomplete. WASM extensions are also sandboxed and can't reliably read environment variables like $PATH directly via std::env::var. worktree.which() resolves binaries through the host process' environment context, which works correctly regardless of whether the worktree is local or remote. This is how the language server binary already handled it:
// src/dart.rs line 37
if let Some(path) = worktree.which("dart") {
MrSubidubi
left a comment
There was a problem hiding this comment.
Alright, let's go with it. Sorry for stalling this for so long, and thank you so much!
Problem
get_dap_binarypassed raw binary names ("flutter","dart","fvm")as commands without resolving them against the host's PATH. WASM extensions
cannot read
$PATHdirectly, so the debug adapter failed to launch on remote(SSH) worktrees.
Fix
Resolve binary paths using
worktree.which(), which works correctly on bothlocal and remote worktrees. This is consistent with how
language_server_binaryalready resolves the
dartbinary.Related Issues
get_dap_binaryresolves locally instead of on the remote host #93