Windows Support

[jonathanmorley]

asdf comprises 2 main parts:

1. asdf CLI
2. asdf plugins

The asdf CLI, being written in bash, does not support running on windows (outside of WSL).
rtx, however, being written in rust, would.

Most asdf plugins are also written in bash, and rtx leans on the asdf ecosystem for plugins.

To address the plugin issue, I propose:

1. Establish an extension to the asdf plugin API to allow plugins to expose new scripts for windows installation logic.
2. Encourage plugin maintainers to add support for windows to their plugin

EDIT FROM @jdx

this work has begun and the major prerequisite can be discussed here: #2051

[jdx]

We would also need to implement the shell code for powershell. I assume this is possible but I don't know for sure.

EDIT: to set expectations: windows support isn't something I'm likely to accomplish. I don't use windows or have much interest in the platform. If someone wants to figure out how to do this I'd be more than happy to work with them and accept a PR though. Discord is always open if you want to chat too.

[rashil2000]

We would also need to implement the shell code for powershell. I assume this is possible but I don't know for sure.

Hi! Although I too would recommend adding PowerShell support for better out-of-the-box experience, it is not strictly required. Bash scripts can already run on Windows without WSL- see my comment here: asdf-vm/asdf#450 (comment)

What does the shell code do? I can try translating it to PowerShell.

[jdx]

It's not just some shell code, rtx is essentially a framework for running shell scripts. It's not in this project, but as an example see the asdf-nodejs plugin which rtx and asdf both use.

Even if we could run things on bash on windows we would still need to make sure the plugins are only using tools that work on windows as well. I suspect just having parallel scripts for powershell that use idiomatic windows tools would be easier—but I'm far from a windows expert here.

[rashil2000]

It's not just some shell code, rtx is essentially a framework for running shell scripts. It's not in this project, but as an example see the asdf-nodejs plugin which rtx and asdf both use.

Oh yes I agree, the plugins would need modifications pertaining to Windows as well.

With rtx advocating for Windows support, plugin authors might be more inclined for Windows support too.

[BasixKOR]

Have you considered leveraging the MSYS2 ecosystem for this? I've used MSYS2-based shell on Windows for 2+ years and I'm generally quite happy with the outcomes. Although using it as a main shell had some pitfalls we could hide it inside rtx as the plugins don't get executed directly by a user.

[onyxraven]

I was wondering about supporting rtx inside msys2/mingw64 as well. I would be interested to start looking into this if there is some demand

[jdx]

I don't know anything about it frankly

[spywhere]

I'm adding my own vision here since I'm also starting my own asdf-clone (I'm new to rust here, so some patterns might be a bit weird) project before finding out about this project and try not to re-invent any wheel here.

I was looking into a more extensible ecosystem and not limited to just shell or power shell. My idea and attempt at it would be using Lua as a plugin's main language and having a set of standardized APIs around it to make it easy to work with. The only requirement for a plugin is to have an entry point to its lua file.

Now for backward compatibility, if a plugin doesn't contain an entry file, we shipped rtx with a default entry point and have it use this script instead (this would make existing asdf's plugins compatible with rtx).

With these Lua plugins, one could leverage the API available to check and perform a corresponding action based on it. So the said default script could look something like this (just to give a brief idea, not an actual implementation)

local M = {}

local exec = function ()
  if api.platform() == 'win' then
    return 'bash'
  else
    return 'pwsh'
  end
end

-- this could take optional arguments to differentiate between list and list all script
M.list = function ()
  -- this is to make it backward compatible with existing asdf's plugins
  api.spawn(exec(), 'bin/list-all')
end

M.download = function ()
  api.spawn(exec(), 'bin/download')

  -- or use shipped API to do it
  api.download('https://example.com/to/download/path', api.fs.temp())
end

M.install = function ()
  api.spawn(exec(), 'bin/install')
end

M.latest = function ()
  api.spawn(exec(), 'bin/latest-stable')
end

-- ... on and on...

return M

The (non-exhaustive) list of APIs I had in mind was something like this...

• plugin -- plugin-related information
  • file(): Given a path to a file in a plugin's directory
• api -- main API to perform arbitrary actions
  • platform(): Returns a platform-specific information
  • spawn(): Spawn a child process and run the command
  • request(): Send an HTTP request with a pre-defined timeout (to keep the plugin performant)
  • download(): Send a GET HTTP request to download a file to a target path
  • read(): Read a file content
  • json -- API to work with JSON data
    • parse: Parse a JSON string into lua table
    • stringify: Serialize lua data type into a string
    • request: A helper function on top of api.request to work with JSON request/response

[toadslop]

I think the most viable solution would be something like this. Trying to hack shell scripts to work on windows is bound to cause headaches. A platform agnostic scripting language is the most viable alternative. The downside is that we'd lose the existing asdf ecosystem since it's built on bash. The upside is that once the existing ecosystem is translated into whatever platform agnostic scripting language we choose, whether its Lua, JavaScript, or anything else) then RTX would become not just an asdf clone, but an asdf replacement. Could be a worthy project.

[toadslop]

I'm interested in working on something like this. Anyone in this thread want to commit some time to doing the following:

1. Choosing a scripting language to embed in RTX and adding it to the project
2. Translating existing asdf scripts into the above scripting language and making them available on github

[toadslop]

Here's another alternative: ShellJs, a portable (Windows/Linux/macOS) implementation of Unix shell commands on top of the Node.js API.

If we use the shelljs-transpiler, assuming it works well, we can transpile the existing asdf scripts to ShellJs and leverage the existing ecosystem for free.

[MrTact]

https://github.com/sagiegurari/cargo-make appears to compile bash scripts into a portable scripting engine called duckscript, which works on Windows. Not sure about the scope of the compilation, though.

[toadslop]

I tested this out on some asdf bash scripts. It's pretty hit or miss. Not a viable solution, I think.

[toadslop]

I've never used it, but apparently the cygwin project is capable of executing shell scripts on windows. Could have a build script for windows that tries to execute cygwin and if it fails, error out and display a message telling the user to install it first. Would need to do some experimenting with it using some actual asdf scripts to make sure it works reasonably well.

[jylenhofdecat]

There's WSL (version 2 is better) now on windows and it works quite well now. Why don't use it ? You can use a lot of Linux distros

[toadslop]

Sometimes you have to do development in a windows environment because of the nature of the project. Running RTX on WSL will not help in this case.

[jylenhofdecat]

https://ubuntu.com/tutorials/install-ubuntu-on-wsl2-on-windows-11-with-gui-support#1-overview

[lokkju]

How about using git-scm's Git Bash as a pre-requisite?
Another useful tool here may be scoop, a windows package manager meant for primarily cli dev tools. It installs all apps in the current user; it may be an interesting option to just have mise shim scoop if on windows, for tool management.

[melMass]

What is the main blocker for this? After reading through I'm not sure to grasp it sorry.
I'm willing to help if I can, I have relatively good knowledge of Unix and Windows

[jdx]

What is the main blocker for this?

someone needs to take it on. It's highly unlikely I ever will.

[onyxraven]

I think the main blocker is that all the asdf plugins are written in bash/sh, and the shimming/aliasing to get the mise environment set up right now is tailored for sh-like language.

in windows, getting to bash/sh requires installing and depending on some posix-like subsystem (wether that be MSYS or WSL).

The mise native plugins will probably work (with some pathing), but at the very least a way to shim into powershell or (yikes) cmd will be needed. That'd be step one. Two would be to direct the user to an appropriate sh subsystem (or maybe link msys/mingw? i dunno), and have mise be aware, to unlock the rest of the asdf ecosystem. Easier said than done.

[jdx]

I mentioned this in #1933 but supporting vfox (which promises good windows compatibility in general) might be a good way to for us to solve the problem of running bash code by using vfox plugins instead of asdf. That isn't everything we need for windows compatibility but it's the biggest chunk of effort for sure.

If anyone wants to contribute to help make mise-on-windows a reality I would consider starting with supporting vfox as a backend first, then trying to get the CLI to execute on windows.

[toadslop]

Who all is interested in working on this? Perhaps we can put together a small working group to tackle this.

[jdx]

I started it, these are the next steps for getting the rust/vfox interface complete: jdx/vfox.rs#4

[jdx]

created a separate discussion for this #2051

[jdx]

very basic windows support is now available for tools. So far python and node seem to work, as well as a handful of vfox plugins. vfox plugins which use the html module do not work yet though—as well as probably several other bugs.

Don't expect it to work well, but I was able to get very simple commands to run at least.