regresssion / feature: [0.16.0] asdf no longer recognizes symlinks as versions

[reneploetz]

Is your feature request related to a problem? Please describe

(Note: this might actually be a regression for a unintended/unsupported feature, so I'm reluctant to classify this as a bug)

Before the change to use Go, it was possible to symlink inside the installs folder to create versions with a stable name. The main rationale was to use them for creating updateable patch versions. These are useful e.g. for Java, where there is a plethora of patch versions that refer to essentially the same version (e.g. for java -> "temurin-21.0.0+35.0.LTS", "temurin-21.0.1+12.0.LTS" etc) - mostly including non-API-breaking security updates.

The issue is that having to reference the exact version in .tool-versions means that if you update, you need to go through the various files to update the number there. This either means you have to keep an insecure version or update the version files individually.

There are at some older reports related to this: https://github.com/asdf-vm/asdf/issues/1622 https://github.com/asdf-vm/asdf/issues/523 https://github.com/andrewthauer/asdf-alias/issues/13

Describe the proposed solution

While I do not necessarily want to open a discussion about an alias core command specifically, I would like to have the symlink functionality restored so that you can write a plugin that does this or create those yourself.

Describe similar asdf features and why they are not sufficient

You can obviously just copy the whole installed version after download - but this means that you need to implement a wrapper around the install/uninstall functionality.

Describe other workarounds you've considered

The only workaround is to copy the installed version as far as I can see.

[Valgard]

Symlinks no longer work, not just for versions but also for plugins. I used to create a symlink to the Git repo of my fork for plugins I'm working on in the $ASDF_DATA_DIR/plugins directory. Now, the plugins are no longer recognized, and asdf plugin add indicates that the plugin is already installed.

[sanel]

Have the same problem: have a bunch of JDK installations (in /opt) for system-wide access and used ~/.asdf/installs/java symlinks, like:

$ ls -la ~/.asdf/installs/java
jdk-11 -> /opt/jdk-11.0.21+9
jdk-11-ibm -> /opt/jdk-11.0.20.1+1-ibm
jdk-17 -> /opt/jdk-17.0.8.1+1
jdk-21 -> /opt/jdk-21.0.1+12
jdk-23 -> /opt/jdk-23.0.2+7
system-java -> /usr/lib64/java

What actaully works is that I have to run asdf reshim java jdk-11 (that will update scripts in /home/sanel/.asdf/shims/java) and repeat that for other links. .tools-versions works as well, but asdf list will show that no java version is installed.

asdf list
java
  No versions installed

[faelin]

+1 — I relied heavily on asdf-alias during python development, but the loss of version aliasing might be enough to make me leave asdf entirely...

Can we please finally make alias a core functionality? So many people have asked for it...

[mrmeszaros]

As I see, asdf is used for two parts:

1. tool install
2. tool selection

Enabling symlinks (or maybe even supporting them with some sort of linking / alias / external install management) would help integrating other tool installers / tool managers.

Personally, there are some external tool managers / downloaders, that I would like to use in conjunction with asdf. Namely:

• Java SDK-s can be downloaded with IntellIJ IDEA - and then linked up to asdf (for auto-select via .tool-versions or .java-version)
• For python I like to use pyenv with pyenv-virtualenv to manage versions
• For protobuf toolchain I like to install some versions with homebrew

I would like to be able to link these up with asdf to have a place to check and manage all tool versions.