Greetings @Stratus3D 👋

These changes are affecting how asdf determines if a version is installed, which is completely unrelated to the process that locates and reads .tool-versions files

Exactly. The previous Bash-based versions correctly detected installed tool versions that were symlinks. However, the current implementation no longer recognizes them, which is a clear regression.

It seems there might be some misunderstanding—this is not about .tool-versions files themselves, but about tool versions and their symlinks. The issue is that symlinked versions, which were previously supported, are no longer detected.

I agree that aliasing should be handled by reworking how asdf selects tool versions from .tool-versions files. However, this PR specifically addresses the regression where symlinked versions, which users actively rely on, stopped working.

Example use case of symlinks:

asdf/installs/nodejs/22.10.0
asdf/installs/nodejs/22.10      -> ./22.10.
asdf/installs/nodejs/22         -> ./22

.tool-versions

nodejs 22

This setup worked in previous versions but is no longer working. Since users depend on this behavior, it seems reasonable to restore it.

Could you clarify do you see an alternative way to address the issue?

My plugin (asdf-go-sdk) has also stopped working due to this issue. However, I have confirmed that this pull request resolves the problem.

From what I can see, symbolic link detection is handled carefully, and the errors module is used for error handling, making it a well-implemented fix that properly restores the previous behavior.

I hope this gets merged and released soon so that my plugin can function again.

Hi @khmm12. The asdf data directory (~/.asdf/ by default) is where asdf is allowed to store plugins, versions, shims, and anything else it needs to store on disk on the computer. It's very important that these directories are not tampered with. The only directories in ~/.asdf that plugins should ever write to are those given to the plugin's callbacks in the *_PATH environment variables - ASDF_INSTALL_PATH, ASDF_DOWNLOAD_PATH, and ASDF_PLUGIN_PATH. The only other place plugins should read/write files is in an OS-provided temp directory.

I'm sorry @yacchi you'll need to alter your plugin so that it doesn't need to write symlinks.

@Stratus3D

Thank you for your response.

I understand the importance of asdf's data directory structure and the need to limit where plugins read and write files. However, the asdf-go-sdk plugin follows the behavior of the Go language itself by utilizing the default installation directory ($HOME/sdk).
This approach ensures compatibility with various tools and IDEs that expect the Go SDK to be in this location.

Changing this directory would break compatibility with these tools, making the development experience more cumbersome. Symbolic links were a solution to bridge this compatibility gap while integrating with asdf.

Given the current restrictions, do you have any suggestions or guidance on how to maintain compatibility with IDEs while adhering to asdf's data directory policy? We would greatly appreciate any ideas or best practices for addressing this challenge.

Thank you for your support and consideration.

@Stratus3D I'd like to echo the concerns of @khmm12 and @yacchi about the current situation. There has been a lot of feedback over the years in #523 that alias versions as a concept is useful. I understand why you don't want it to become a core feature of asdf itself, but I'd like you to consider the practical reality of how asdf is used by many of its current users (plus the people who switched to Mise because of missing features like this one). The asdf-alias plugin was born to fill this gap, and while I agree that it's an imperfect solution, it is a practical fix for the current situation where the version alias concept is not a core feature of asdf itself.

Thank you for considering our use case, and I really hope we can find a way forward that fits everyone.