Feature: Per project installation of SDK

[MateuszKubuszok]

• [x] I have read the CONTRIBUTING guidelines
• [ ] I've had a conversation on the #cli-development Slack channel about this request.

Feature request

GraalVM besides providing JDK API also adds polyglot applications. Not all languages are embedded in a standard installation so one might need to run:

# gu comes from GraalVM after it's been installed and set up by e.g. sdkman
gu install native-image
gu install python
gu install ruby
$JAVA_HOME/languages/ruby/lib/truffle/post_install_hook.sh
gu rebuild-images --verbose polyglot python ruby

The problem is that these are modifying the global installation of a GraalVM, so if 2 projects wanted to have different things installed, the user would have to explicitly use different versions of GraalVM to make sure that they aren't accidentally using features are not explicitly requiring by their project.

Ideally, sdkman could create a separate sdk name for e.g. GrallVM in some particular version with some extra languages installed and their images rebuild, but it might be easier to make sdk man install sdk in some directory local to project (and defining this directory wth sdkman env file) allowing it to modify it freely without installing components for the whole system.

[linghengqian]

• As a reminder, all implementations of graalvm truffle are now decoupled from the graalvm ontology, and all provide independent versions of binary, including but not limited to graaljs, graalwasm, graalnodejs, espresso, and truffleruby.

• GraalPy is now available through pyenv, the most popular SDK manager in the Python world.

• I even opened https://github.com/oracle/graal/issues/9518, https://github.com/oracle/graal/issues/8234 for this. One issue is to request to make graalnodejs ready on the two most popular SDK managers in the nodejs world, and the other issue is to request to release IGV to the most popular immutable software repository in the Ubuntu world.

• Now the current issue actually becomes, should sdkman try to include the responsibilities of pyenv, nvm, nvm-windows, snapcraft?

[MateuszKubuszok]

Hmm, my original use case was using several languages inside the same VM, e.g. calling Pygments or KaTeX libraries from withing JVM, and GraalVM allowed me to do it, although it required running gu. If I needed to use several package managers inside a single project, I would probably rather use other libraries and/or reimplement functionalities I need myself.

[linghengqian]

Now, gu is no longer in graalvm-ce. I don't see the way forward for the current issue.