This change adds two things to our remote server build
process:
1. It now checks if all required tooling is installed before using it or installing it on demand. This includes checks for `rustup` and `cargo-zigbuild` in your `PATH`.
2. Next, if `ZED_BUILD_REMOTE_SERVER` contains `musl` and `ZED_ZSTD_MUSL_LIB`
is set, we will pass its value (the path) to `cargo-zigbuild` as `-C
link-arg=-L{path}`.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/41260
After experimenting and reading through the implementation of OpenSSH
stack on Windows, it looks like batch mode precludes use of passwords.
In the listing
b8c08ef9da/sshconnect2.c (L417),
the last field of each `Authmode` struct is a pointer to the config
value that *disables* that particular mode. In this case, `keyboard`
(interactive) and `password` modes are both disabled if batch mode is
used. We should therefore fall back to `scp` if `sftp` fails rather than
to fail outright.
Release Notes:
- N/A
Using `shlex` unconditionally is dangerous as it assumes the underlying
shell is POSIX which is not the case for PowerShell, CMD, or Nushell.
Therefore, whenever we want to quote the args we should utilise our
helper `util::shell::ShellKind::try_quote` which takes into account
which shell is being used to actually exec/spawn the invocation.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Closes#37322
Uses SFTP if available, otherwise falls back to SCP for uploading files
and directories to remote. This fixes an issue on older macOS versions
where outdated SCP can throw an ambiguous target error.
Release Notes:
- Fixed an issue where extensions wouldn’t work when SSHing into a
remote from older macOS versions.
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
Follow-up to #39248
- Correctly forward ports over SSH, including the port from the debug
scenario's `url`
- Give the companion time to start up, instead of bailing if the first
connection attempt fails
Release Notes:
- Fixed not being able to launch a browser debugging session in an SSH
project.
This PR adds support for browser debugging in SSH and WSL projects. We
use the vscode-js-debug-companion extension, repackaged as a standalone
CLI (https://github.com/zed-industries/js-debug-companion-cli).
Closes#38878
Release Notes:
- debugger: Browser debugging is now supported in SSH and WSL projects.
---------
Co-authored-by: Nia <nia@zed.dev>
Closes#38538
Release Notes:
- Fixed an issue where opening a remote terminal failed on systems like
BusyBox, Alpine, Amazon Linux 2, some CentOS images, etc., due to an
invalid option 'C'.
BusyBox's off brand `wget` does not have support for the `--method`
argument, which makes `zed` incapable of downloading the remote server
unless the _☙authentic❧_ one is installed. Removing this should fix the
issue. Couldn't find much about guidelines on how the code is supposed
to be formatted, so I opted for commenting the line out with an
explanation.
Closes#38712
Release Notes:
- Fixed remote development on BusyBox
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
The built-up command for the WSL remote connection looks like
```
wsl.exe --distribution Ubuntu --user cole --cd /home/cole -- bash -c SCRIPT
```
Where `SCRIPT` is a command itself. We don't need extra quotes around
`SCRIPT` because we already pass it whole as a separate argument to
`wsl.exe`.
This isn't yet enough to get ACP servers working in WSL projects
(#38332), but it removes one roadblock.
Release Notes:
- windows: Fixed an issue that could prevent running binaries in WSL
remote projects.
This reverts commit bf5ed6d1c9.
We believe this may be breaking some users whose shell initialization
scripts change the working directory.
Release Notes:
- N/A
On nightly, when I run `zed` under WSL, I get an error parsing the
shebang line
```
/usr/bin/env: ‘sh\r’: No such file or directory
```
I believe that this is because in CI, Git checks out the file with CRLF
line endings, and that is how it is copied into the installer.
Also, the file extension was incorrect when downloading the production
remote server (a gzipped binary), preventing extraction from working
properly.
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/36764
* Fix `anyhow!({e})` conversion lossing Collab error codes context when
opening a buffer remotely
* Use this context to only allow opening files that had not specific
Collab error code
Release Notes:
- N/A
Instead of manually constructing the venv we now ask the python
toolchain for the relevant information, unifying the approach of vent
inspection
Fixes https://github.com/zed-industries/zed/issues/27350
Release Notes:
- Improved the detection of python virtual environments for terminals
and tasks in remote projects.
This is a pure refactor that consolidates all SSH remoting logic such
that it should be straightforward to add another transport to the
remoting system.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Closes #ISSUE
Release Notes:
- The environment of original remote dev cannot be changed without sudo
because of the behavior of "sh -c". This PR changes "sh -c" to "sh -lc"
to let the shell source $HOME/.profile and support customized
environment like customized $PATH variable.
