Windows support? Docs & tests for WSL2

[jayvdb]

It would be great to have core support for windows, assuming it has git bash or similar, with Appveyor CI keeping it from breaking.

[abhishalya]

I would like to work on this issue :)

[jthegedus]

I know this will not help with CI tools, but just so it is documented in this thread for those who are looking for personal Windows use. I've used asdf-vm inside Windows 10 via WSL (Ubuntu) many times over the past two years. Following the Ubuntu Bash setup is compatible with using WSL.

[earonesty]

no idea why this is closed. installation on windows is definitely not supported. wsl2 is not helpful at all for unit testing or ci/cd of tools that are designed to run on windows clients and servers. be cool if it was some day. is there a ticket to track that?

[rainecheck]

no idea why this is closed. installation on windows is definitely not supported. wsl2 is not helpful at all for unit testing or ci/cd of tools that are designed to run on windows clients and servers. be cool if it was some day. is there a ticket to track that?

Agreed. No references to Windows, Powershell, Git-Bash etc in Getting Started. Installation instructions list Linux and macOS specifically, but not Windows. It might be that support for Windows is there, but not documented; perhaps a separate "Add installation instructions for Windows" issue needs to be created, if this will not be reopened.

It looks like this commit references cygwin specifically.

[jthegedus]

Hi all,

When people discuss Windows support, I expect they mean "native" Windows support (see #1246), which typically does not refer to installing an entire Shell/Linux ecosystem/toolchain. This is why I always discuss Windows support in the context of WSL, which is the official Windows model to support Linux tooling, which I consider asdf to be. I have no idea how much work would be involved in supporting an environment like Powershell. Most other tools in this space have a specific separate repo for their Windows implementation as it differs so much from the Shell implementations.

We can do better with the documentation. Specifically a Windows section pointing out that it is possible to run asdf under specific conditions, like WSL, on a Windows machine. How helpful it is calling WSL2 "Windows support" I think is up for debate. Nonetheless, documentation is an area of improvement.

no idea why this is closed. installation on windows is definitely not supported. wsl2 is not helpful at all for unit testing or ci/cd of tools that are designed to run on windows clients and servers. be cool if it was some day. is there a ticket to track that?

As this thread indicates, at one stage we did use Appveyor to run tests on Windows, however it was still just using cygwin\bin\bash. As this is not native Windows support, calling it Windows support is questionable IMO. Additionally, I think expecting this repository to run tests against every conceivable way of running Bash on Windows is unreasonable, especially when Microsoft ships WSL2 as the sanctioned way of running Linux tooling on Windows for developers. That isn't to say we couldn't pick a few tools like Cygwin/Git-Bash etc. But you can see how that is not so much a priority when WSL works mostly as intended.

#465 is an issue tracking Windows testing via GitHub Actions. The goal I had with the ongoing conversation there was to get WSL2 in GitHub Actions executing to capture any issues with WSL2 support. Again, because WSL2 is the MS sanctioned way to run Linux software. Unfortunately, setting up WSL2 on GitHub Actions is non-trivial, so we haven't resolved that as yet.

As for this ticket being closed. It was closed when Appveyor tests were merged. Given Appveyor was reverted, it seems reasonable to reopen this ticket, though I think it's intent should be reclarified.

My proposition for this ticket is this:

• document Windows support via WSL2. Note other tools like Cygwin/Git-bash etc may work but are not officially tested
• get WSL2 in GitHub Actions working as tracked in Failing tests on windows. #465

[jthegedus]

As for

wsl2 is not helpful at all for unit testing or ci/cd of tools that are designed to run on windows clients and servers

asdf, in its current form, is not intended to run on Windows natively. It requires execution of Shell scripts and *nix tooling.

[airtonix]

instead of gitbash, look at working with winbash, its more idiomatically windows like (you can use sh.exe and grep.exe inside a powershell instance)

[airtonix]

another option is rewrite asdf in golang so binaries for linux/mac/win can be created.

i mean the basic principles here are the shims the win on the PATH right?

[hotdang-ca]

So... where are we on this? I could take this on, as I have helped my team manage their dart versions with asdf on Windows + WSL2. Everything is a-ok (with Ubuntu, at least).

[ogrotten]

asdf, in its current form, is not intended to run on Windows natively. It requires execution of Shell scripts and *nix tooling.

This line, exactly like this, should be added to the documentation. In the absence of a clear statement, the user is left to wonder if they missed something.

[jthegedus]

asdf, in its current form, is not intended to run on Windows natively. It requires execution of Shell scripts and *nix tooling.

This line, exactly like this, should be added to the documentation. In the absence of a clear statement, the user is left to wonder if they missed something.

We can expand the FAQ to explicitly include this - https://asdf-vm.com/learn-more/faq.html#wsl2-support. Would that suffice @ogrotten ?

[lhauspie]

I think the good URL is this one 😉 ==> https://asdf-vm.com/more/faq.html#wsl2-support

[ogrotten]

@jthegedus That is a good treatment, thanks.
@lhauspie that is the link, thanks,

[shinayser]

another option is rewrite asdf in golang so binaries for linux/mac/win can be created.

i mean the basic principles here are the shims the win on the PATH right?

Another option would also be rewriting it in PowerShell since it is multi platform.

[rashil2000]

asdf, in its current form, is not intended to run on Windows natively. It requires execution of Shell scripts and *nix tooling.

Nit: I still don't feel this is accurate, or rather the justification here is not accurate. All unix shells (bash, zsh, fish, tcsh, ksh etc.) can run on Windows using Cygwin/MSYS2/GitBash, without any involvement of WSL. Plenty of unix tooling is available too (see https://packages.msys2.org/package/?repo=msys and https://packages.msys2.org/base, for example). A more accurate explanation might be that developers are not currently considering supporting another platform (due to added maintenance burden, or due to lack of Windows machines, or the likes).

[airtonix]

I love a good bikeshedding topic:

another option is rewrite asdf in golang so binaries for linux/mac/win can be created.
i mean the basic principles here are the shims the win on the PATH right?

Another option would also be rewriting it in PowerShell since it is multi platform.

No one is going to download powershell just so they can run asdf. The idea behind writing it in golang (I actually don't care if it is golang) was that golang makes it's stupidly easy to generate binaries for all platforms (as in using golang there should not be any excuses as to why platform X doesn't have a binary).

Powershell on the other hand. yeah nah.

[lmilbaum]

How about baking a container image with the tools? Would that address the ask?

[shinayser]

How about baking a container image with the tools? Would that address the ask?

What about using wsl to run the scripts but storing the actual packages on the windows filesystem side?

[jthegedus]

Nit: I still don't feel this is accurate, or rather the justification here is not accurate. All unix shells (bash, zsh, fish, tcsh, ksh etc.) can run on Windows using Cygwin/MSYS2/GitBash, without any involvement of WSL.

My historical usage of these solutions (Cygwin/MSYS2/GitBash) on Windows was that they each had their own set of caveats. WSL is the Windows native supported model for Unix on Windows, so that is why it is the initial target. Cygwin/MSYS2/GitBash etc may also be valid for us to add to our test suite, but not the initial focus. WSL is our initial Windows support focus.

[rashil2000]

WSL is the Windows native supported model for Unix on Windows

It's not native - WSL is just Linux running in a Hyper-V VM. Any application/software/tooling development that concerns "Windows" cannot be done using WSL.

WSL was created to aid in Linux-env development, for people who used Windows as their daily OS, and didn't want conventional VM solutions or a dual boot.

And as far as I know, nothing additional is required for WSL support - all Linux instructions work on WSL because it's a Linux VM in the end, i.e. Ubuntu or Fedora or openSUSE etc.

[jthegedus]

By "native" I mean the sanctioned method by Microsoft to perform Linux activities on a Windows machine, of which, this is a Linux tool.

From my position, we do not actively "support" WSL because we do not run our test suite against a WSL environment. I know from experience that some of our tests do fail under a WSL environment, as with Cygwin & co. So, for us to list WSL as officially supported, I would like test automation to perform that validation and any issues resolved.

Whilst true WSL is essentially a Linux VM of various Linux OSs, there are differences with Ubuntu in WSL to native Ubuntu. What those are I am not 100% certain of because I haven't delved into the reason for the failing test suites when run in WSL, but they do exist so therefore no "Official WSL support".

[airtonix]

How about baking a container image with the tools? Would that address the ask?

How about baking a container image with the tools? Would that address the ask?

What about using wsl to run the scripts but storing the actual packages on the windows filesystem side?

These two suggetions are just variations of "run it in linux"

The whole point of getting to working outside of :

• docker
• wsl2
• other linux vms

Is so we can run tooling to compile/run windows things.

This would end up replacing tools like scoop which do not pin installed tools to a version.

@jthegedus it would be great if this statement

It requires execution of Shell scripts and *nix tooling.

could be detailed for contributors so we can collaborate more effectively to work out what it is that is preventing asdf from running in these environments:

Latest version for the following Windows platforms:
- Git for Windows Bash (MSYS2 based)
...
- MSYS2
- Cygwin

• also https://win-bash.sourceforge.net/

#1436

[Stratus3D]

Uh... for some reason this got closed again because of #592. Not sure why 🤔

@jthegedus this got closed due to a commit on asdf-vm/asdf-core-rust. Any idea why?

[chadlwilson]

@Stratus3D FWIW, the email message sent to me at the time said "Closed #450 as completed via 7d5d62c." which is the commit in this repository that claimed to close this issue as part of #451 .... but still not sure why it popped up again :-)

[airtonix]

fyi, anyone looking for a solution to this can checkout https://github.com/aquaproj/aqua. seeks to do the same thing as asdf but it's written in Golang. 🎉

[aooohan]

fyi, since this issue hasn't been resolved for a while. I've spent some time developing a CLI tool that operates in the same manner as asdf, providing capabilities through plugins and support native Windows, non-WSL.

docs: https://vfox.lhan.me/
repo: https://github.com/version-fox/vfox
plugins: https://github.com/version-fox/vfox-plugins