Sdkman-cli: Bug: a GraalVM environment initialized with SDKMAN overrides `node` binary

[pshirshov]

This is a common problem with all the environment management tools.

Let's assume I have a local GraalVM environment initialized with SDKMAN:

work/tut/sdkman-test via ☕ v11.0.8 on ☁️  eu-west-1
❯ cat .sdkmanrc
# Enable auto-env through the sdkman_auto_env config
# Add key=value pairs of SDKs to use below
java=20.2.0.r11-grl

This would hopelessly override my node binary:

work/tut/test via ☕ v11.0.8 on ☁️  eu-west-1
❯ which node
/Users/pavel/.sdkman/candidates/java/current/bin/node

This is very inconvenient because I have a heterogeneous project which requires both node and java but GraalVM's node is like 2 times slower than original one.

I believe there must be a way to disable overrides for some binaries. E.g. .sdkmanrc may contain something like:

java=20.2.0.r11-grl
ignore=node

[helpermethod]

Hi @pshirshov!

This can be easily fixed by using an alias

alias node=/path/to/your/node/binary

[pshirshov]

Nope, subprocesses wouldn't honor aliases. Moreover, my primary shell is zsh while my automation scripts are mostly in bash and scala.

[pshirshov]

For those who may experience the same problem: I made an alternative dependency manager: https://github.com/7mind/binlink

It does a bit smarter job and gives the user more precise control on dependency linking.

[marc0der]

This problem could be easily fixed with a post-install hook in our sdkman-hooks service, that is exactly what the hooks are for. For instance, we could simply take away executable rights on the node (and any other) binary. We could even remove those files all together.

@pshirshov just a quick observation about the above comment. You are completely entitled to building your own tool to rival the likes of SDKMAN, jenv or others, after all this is a free and open world. However, in the future please don't use our issues or public forums as a means of self-promotion for your own tool. It's simply not cool.

We would like to see SDKMAN become better over time, so we're always open to ideas and inputs and we welcome pull requests to make this tool better for everyone to use.

[goeh]

It took me a while to figure out why my Vue.js application suddenly took 20 minutes to start instead of 20 seconds! Realized after a lot of frustration that I used ~/.sdkman/candidates/java/current/bin/node that came with the GraalVM installation I did last week.