asdf-vm/asdf

Provide a way to add or link up externally installed tool versions

mrmeszaros opened this issue · 3 comments

Is your feature request related to a problem? Please describe

I have many java versions installed on my machine by different ways: like homebrew or IntellIJ IDEA.

I want to be able to manager them from a singular place, and currently asdf does not have an extension point.

Describe the proposed solution

Proposal no. 1:

Add a new command that plugins can implement: asdf add <plugin> <version-name> <path-to-install-location>
For example:
asdf add java azul-11.0.20-aarch64 ~Library/Java/JavaVirtualMachines/azul-11.0.20-aarch64/

  • This would make the given version name be available for chosing with asdf shell|local|global <plugin> <added-name>
  • Could be also named asdf link, since it links up versions.

Proposal no. 2:

Make the existing install command work with local paths: asdf install <plugin> <path-to-install-location> --name=<version-name>

This would be probably more elegant way to handle things for the CLI - however, it needs to be designed a bit more carefully, to make it's usage simple and easily discoverable.
Maybe:

  • asdf install <plugin> <version-name>
    • tries to install if it exists in the downloadable versions.
  • asdf install <plugin> <version-name> --from=<path-to-install-location>
    • checks if the version name is downloadable, and warns the user?
    • links up the version to point to the specified location
    • considered other names: --local or --location

Describe similar asdf features and why they are not sufficient

  • asdf alias plugin:

    • pro: creates linked versions
    • con: made for another purpose - links to the same directory
    • con: seems like something that should be a core functionality (as it refers to other plugin install versions)
  • asdf install:

    • con: tried if it supports it already, but it does not

Describe other workarounds you've considered

Manually creating symlinks between the local install locations and the respective asdf plugin install directory.

This does not work for me: the java plugin has java_macos_integration_enable that makes it work nicely with MacOS's /usr/libexec/java_home.

In this scenario, the solution I would propose is to:

  • uninstall the conflict with Homebrew as you're not really managing the version via asdf since it can't update or remove the Homebrew installed version
  • for editors, you can usually configure which version they point to in the settings, so set it to the asdf managed version of Java.

I don't believe this is a feature we wish to support. The scope is huge with high potential for errors as other tools add, remove or change the "linked" tool.

@jthegedus understandable.

I currently have two main issues:

  1. Java on MacOS is well integrated within the ~/Library/Java/JavaVirtualMachines/ folder.
    One can use the /usr/libexec/java_home binary to list and select valid JAVA_HOMEs.

  2. The other is, that currently I need java installed for different architectures: x86_64 and aarch64
    However, asdf does not have versions for different architectures (or more precisely the java plugin does not have them).
    JetBrains's IntelliJ IDEA can download versions for different architectures, and it puts them into the ~/Library/Java/JavaVirtualMachines/ folder.

Both point me towards having java versions installed under ~/Library/Java/JavaVirtualMachines/.
This conflicts with asdf's vision of having it all in one place in ~/.asdf/installs/java/.


I might be beating a dead horse here, but: how I imagined asdf add $TOOL $NAME $LOCATION to record the info that the added version is managed externally, and warn the user that asdf will not try to manage it.


Lastly, how I see currently that asdf tries to be both a universal tool installer and selector but misses the features to install and select tool versions for other architectures.

Edit, PS.: I just read it again - I hope I do not sound rude.