Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mrmeszaros opened this issue Aug 25, 2023 · 3 comments
Open

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

mrmeszaros opened this issue Aug 25, 2023 · 3 comments

Comments

@mrmeszaros
Copy link

mrmeszaros commented Aug 25, 2023

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.

@jthegedus
Copy link
Contributor

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.

@mrmeszaros
Copy link
Author

mrmeszaros commented Oct 21, 2023

@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.

@tomwhoiscontrary
Copy link

tomwhoiscontrary commented Nov 8, 2024

I would also like this feature. I use asdf to install Java development kits (JDKs), using halcyon/asdf-java. Mostly this works as usual, downloading and shimming them automatically. However, a few projects i work on require particular ancient versions (patch releases of 1.8.0), which are not available through asdf-java, and never will be.

I can install these from tarballs which we have downloaded and preserved. But i have no good way to actually use them. My system is set up to use asdf to manage Java, but asdf does not know about these versions.

There is the idea of the "system" version, but that doesn't help here, because these ancient JDKs are not my system JDK, and it would not be appropriate to make any of them my system JDK.

I have managed to kludge my asdf installation to use these ancient JDKs; i added a symlink to the installs directory:

ln --symbolic /opt/java/jdk1.8.0_45 /home/tomwhoiscontrary/.asdf/installs/java/extern-jdk1.8.0_45

And then modified the java, javac, and jar shims to add:

# asdf-plugin: java extern-jdk1.8.0_45

This all seems to work fine. I can run these commands, and use asdf uninstall to remove the symlink and the asdf-plugin metadata.

But obviously, this is a bit sketchy! If this is all that is required for this to work, then at first glance it seems like it would be simple to expose a command to do this in a supported way.

EDIT: i realised after writing this that i don't need to add the asdf-plugin lines myself, i can add the symlink and then reshim.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants