metcalfc
commented
8 months ago The way that I currently have worked around this is that my WSL install does Windows PATH sharing and I've got an alias for daytona.exe in my dotfiles. So if daytona.exe is on the PATH, we use the Windows binary from INSIDE wsl2. Which is effectively what the code binary is doing. This works fine. I can create and list. I don't use any of the port forwarding.
Mirroring the way code does it makes sense given the relationship between daytona and code.
# Daytona doesn't work on WSL, so we will use the Windows version
# if it is available on the PATH. This is the same approach as code
# and docker use.
if [[ $(uname -r) =~ Microsoft$ ]]; then
if command -v daytona.exe >/dev/null 2>&1; then
alias daytona='daytona.exe'
fi
fi
Is your feature request related to a problem? Please describe.
Running Daytona on WSL2 doesn't work for VSCode IDE as VSCode uses the native Windows SSH client and Daytona edits the Linux SSH config file to prepare SSH connection configs for workspaces. This wouldn't pose an issue most of the time, but Daytona uses a ProxyCommand under the hood which calls "daytona ssh-proxy" and is defined in the SSH config that naturally searches for the daytona binary on the Linux part of the filesystem.
Describe the solution you'd like This isn't a Daytona specific issue, rather a missing feature from the remote development plugin. Ideally, we could pass a "remote ssh path" flag when calling the "code" CLI and set it to the ssh of our choice. We can create a ticket to see if this is doable with the official support but until then we should consider another option.
One way to fix this is to show the user the instructions / make script that can be run from WSL to:
C:\Windows\system32\wsl.exe ssh %*atC:\Users\<USERNAME>\AppData\Roaming\bin\wsl_ssh.bat"remote.SSH.path": "C:\\Users\\<USERNAME>\\AppData\\Roaming\\bin\\wsl_ssh.bat", atC:\Users\<USERNAME>\AppData\Roaming\Code\User\settings.jsonln -s /mnt/c/Users/<USERNAME>/.ssh/config configThis would be a
hack/windows/vscode_wsl_ssh.shscript with a couple of lines of bash code.*To check if the current installation is in WSL we can do
uname -aand see if it contains "microsoft"/"WSL". Based on that we can then print out instructions or a docs URL to the user. User would be able to do the steps manually if they prefer it instead of running the script.Additional context
A problem with this option is that the user might not want the default SSH client to be the WSL client as this would affect all VSCode operations that use SSH, even outside of Daytona. It can be investigated further if creating a VSCode "profile" for Daytona would be feasible as it would have its own set of config settings. The "--profile" flag is available for use in the "code" CLI and this profile would be only used by Daytona, allowing the user to continue using their default profile for other work.
Another approach is to see if a Daytona VSCode extension could resolve this by handling the SSH client switching part.