Windows support without WSL?

[chase]

Do you plan to ever support Windows without using WSL?

It would be wonderful to launch on my Windows instance in KVM and run distant.nvim from the Linux host, the exact opposite of WSL.

What is currently preventing a native Windows build?

[chipsenkbeil]

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.

[chipsenkbeil]

@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.

[chase]

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

[chipsenkbeil]

@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.

[chipsenkbeil]

@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.

[chipsenkbeil]

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. 😄

[chipsenkbeil]

@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.

[chipsenkbeil]

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.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.