Windows support without WSL? about distant HOT 8 CLOSED

@chase the distant binary now compiles on Windows via MSVC, but I've yet to test it to see if launching works. It's close to being ready, though. I just don't have an automated test to verify launching and don't have a windows machine available.

from distant.

Yes, I do! But I don't have a windows machine to actively test in rapid development.

distant-core already supports windows. The cli has a couple of minor unix-only features that need to be excluded such as forking on launch, otherwise it was also designed to be platform agnostic.

The distant.nvim plugin needs to have its path handling updated to detect windows and use appropriate path separators instead of assuming backslash.

from distant.

@chase, I've opened #52 to reflect the main missing feature to support windows for the binary. If we get this working, I think we can compile a feature-complete distant binary for windows. When we use distant launch to start up a server, we need to be able to spawn the server and detach it from the SSH session, otherwise the server would be killed when SSH closes.

On Unix platforms, we use fork. On Windows, we'll need to do a traditional child process spawn and then detach it. We also need to properly test this in some automated fashion. I previously used Appveyor for older projects when I wanted Windows support. I don't know if it offers a non-WSL option for free, or if there's another modern option. It seems like Github Actions for Windows just stick with WSL, unless I'm missing something.

from distant.

On Unix platforms, we use fork. On Windows, we'll need to do a traditional child process spawn and then detach it. We also need to properly test this in some automated fashion. I previously used Appveyor for older projects when I wanted Windows support. I don't know if it offers a non-WSL option for free, or if there's another modern option. It seems like Github Actions for Windows just stick with WSL, unless I'm missing something.

It seems like you can use it on a Windows runner with and without WSL:
https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell

Edit: Actually, it looks like you're running without it already because it isn't set explicitly as your default shell:
https://github.com/Vampire/setup-wsl#default-shell

from distant.

@chase, good to know! I remember that I had to disable a couple of tests for Windows on distant-core because they were testing remote process communication using bash scripts. For some reason, Rust was detecting windows and trying to use a path like C:\path\to\test.sh but this failed not because it was bash but because the cmd wanted /path/to/test.sh so I just assumed it was running in WSL.

Worth taking a look again at some point. I'm also unfamiliar with Window's batch cmd syntax, and would need help generating equivalent test scripts as seen in tests/cli/action/proc_run.rs.

from distant.

Once #60 is resolved, we should have native binaries released for all major platforms without me needing to build them on my local machine and copy them over. Be on the lookout for that as I'll need some help testing it. 😄

from distant.

@chase give https://github.com/chipsenkbeil/distant/releases/tag/v0.15.0-alpha.7 a try. Once again, Windows is not tested. This just compiles.

from distant.

This has now been tested and has CLI checks that verify that distant can run and function properly on windows in both directions: as a client connecting to a remote server, or as a server listening for remote actions to perform. Closing out as 0.17.x includes the windows functionality properly.

from distant.