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:
-
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 validJAVA_HOME
s. -
The other is, that currently I need java installed for different architectures:
x86_64
andaarch64
However,asdf
does not have versions for different architectures (or more precisely thejava
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.