#4569 [Feature Request]: Don't resolve symlinks for runtimes

Problem Statement

Environment

Running on macOS, I have both brew and mise installed. Mise allows me to have multiple runtimes for dev tooling installed and then switch between them, etc. much like asdf.

Situation

Homebrew requires node to be installed for many packages it manages. I link to the homebrew installed version using a link defined in mise (e.g., mise link node@brew "$(brew --prefix node)". This link exposes the current version of my homebrew node installation to mise for use.

Going into the Wox control panel for runtime settings, I was informed that the node runtime could not be found. No problem, I thought, I will just set the value for the runtime in Wox to my homebrew one, as it is stored at /Users/{USER}/.local/share/mise/installs/node/brew/bin/node. However, when I added the path into the control panel and then opened the control panel back up to check if the runtime was found, the link to the runtime was no longer the alias but the actual path, in this case, /usr/local/Cellar/node/26.8.1/bin/node.

Problem

The package managers use symlinks to maintain the path entries etc. For example, brew enables me to use the $(brew --prefix node) command to link to the path of the currently installed node version, enabling version updates to occur and not break scripts or other tools. Because Wox dereferences the symlink, it binds to a specific version. Thus, if node is upgraded, I have to manually go back in and update the runtime engine.

Workaround (yikes!)

After reading the code, I went into the wox.db file and edited the value for the node runtime. I then opened up Wox. Interestingly, not only did the UI just display the value stored, it also had already loaded node from the symlinked path. So, it's not that Wox cannot use the symlink. The UI resolved the symlink and stored the target and not the path to the symlink.

Proposed Solution

Enable symlinks to be stored for the path to a runtime executable engine via the user interface. Wox does work if the symlink path is directly entered in the wox.db, so it does not appear to be a functional limit. Rather, the UI just currently resolves the alias when it saves to the settings DB, requiring some workarounds for package-managed version control of runtime engines.

Note that I did see the comments made when handling the python path about the bug fix, but only persisting the resolved path and not the symlink introduces issues later that can be avoided IMHO.

Alternatives Considered

Options

Test path, but store symlink

You can test the path before saving, and if really required, store the path to the linked file separately. Just don't resolve the symlink until required.

Add `mise` to the common locations testing done

You can add mise to the common locations that are checked. If mise is installed, running something like mise ls -g node --json will return back a JSON structure that will have all the information for the global runtime.

[
  {
    "version": "brew",
    "requested_version": "brew",
    "install_path": "/Users/{USER}/.local/share/mise/installs/node/brew",
    "source": {
      "type": "mise.toml",
      "path": "/Users/{USER}/.config/mise/config.toml"
    },
    "symlinked_to": "/Users/{USER}/.local/share/mise/installs/node/brew",
    "installed": true,
    "active": true
  }
]

From there, the JSON gives you the global entry directly, including `install_path` (the directory, not the binary itself, so append `/bin/node`).

I'd also look at asdf, as it most likely has the same issue.

Platform

macOS

Wox Version

v2.4.3

Additional Context

Multiple Runtime Version Manager for Development Tooling

mise
asdf

I won't go into jenv, pyenv, rbenv, or any of the other single language toolsets.

[Feature Request]: Don't resolve symlinks for runtimes