Sdkman-cli: Per project sdk configuration

[ctranxuan]

Please tick one:

• [X] this is a new Feature Request, a conversation was started in the Gitter CLI Development Room.
• [ ] this is a new Bug Report or Issue, a conversation was started in Gitter User Issues Room.

Please explain the Issue / Feature Request here:

Assume you have an environment managed with sdkman such as Java 11 by default, Maven 3.6.0 by default, etc.
But you have a project that requires Java 8 and Maven 3.5.3. It would be convenient if every-time you enter to the directory of the project, all your environment is setup with Java 8 and Maven 3.5.3 without having to settle it manually through multiple sdk command lines.

jenv.io has such nice feature (https://github.com/linux-china/jenv#jenvrc-support): it's addressed through a jenvrc file that contains the version of libraries we wish to customize. Then, you call a command jenv init that settles the right versions.

Proposed feature: being able to declare a sdkmanrc into a directory that would contain tools versions and a command sdk init that would set for the tools the versions declared in the file sdkmanrc

Example:
By default, we have java 11 and maven 3.6.0.
In the directory my-project, we have a sdkmanrc files that contains:

java=1.8.0_112
maven=3.5.3

Then doing:

cd my-project
sdk init

would setup the environment to java 1.8.0_112 and maven 3.5.3.

[marc0der]

Per project sdk configuration

[marc0der]

I would be keen on taking this a step further. How about we introduce a new top level env command. When you do an sdk env init, it will _create_ an .sdkman file in the current directory with all the current versions set in that shell.

Say you opened a shell and then used sdk use to set a different version of java, this new version of java (along with any other candidate versions installed with sdkman already) will be written in this file. To recall the versions, a simple sdk env (or sdk env load) would use all of those in the current shell.

A proposal was also made by @EugenMayer that we add support for language specific descriptors like .java-version or .gradle-version etc. This should be simple to do, although the preferred method would still be to use an .sdkman file instead. I'm happy to support using both though.

[lalloni]

So, how about instead of using an sdkman-specific config file, sdkman could use something that could be shared among similar tools so we can commit such file without cluttering projects with config files for multiple tools.

I'm thinking sdkman could just use the .tool-versions file that asdf uses. sdkman can use that file since is has a very simple format very similar to the proposed above; and it is not, at least in name or format, specific to any tool.

Think of this as what .editorconfig file has done as a standard way of configuring editor preferences for each project that can be read and honored by multiple editors/IDEs, to great benefit.

[marc0der]

Sounds like a great idea, although there is no harm in supporting both.

[helpermethod]

Hi @marc0der!

I would like to take a stab at this, as I think that functionality would be a great addition to SDKMAN.

I've already created a working SDKMAN extension which supports reading the environment settings from an .sdkrc file here.

[lalloni]

Again, as I said above, in case you missed it. I think that, ideally, this is a feature shouldn't be specific to this or any other tool but be usable across tools.
With that I mean is that instead of using an sdkman specific .sdkrc file we should aim to use something other tools already understand, like the .tool-versions file that asdf understands as well as other tools.
This standardization should benefit all tools and facilitate adoption from other tools like IDEs or editors.
While it would certainly benefit my teams by not needing to keep in sync the configuration files for all tools each project use, it while also avoid polluting the projects with configuration files for all the tools the different members of the team use. This is particularly applicable to open sources projects where there is great variance in what tools each developer use.

[helpermethod]

@lalloni Agreed. I will change the extension to support .tool-versions instead.

[marc0der]

@helpermethod as suggested in the above thread, would you be able to make it support both? In other words, both .tools-version and .sdkman.

[helpermethod]

@marc0der .sdkman or .sdkrc? It should be no problem supporting both but I would question if .tools-version wouldn't be enough?

Would result in less code, less things to test, and .tools-version seems to be familiar to users of asdf-vm.

I'll give it a try, though :).

[helpermethod]

So the extension now supports both formats (.sdkrc and .tool-versions).

But I wonder if the users of the .tool-versions won't run into trouble when using both sdkman and asdf because we probably can't guarantee that both version managers are able to provide the same candidates/versions, no?

sdkman for example supports jbang whereas asdf does not.

Maybe we should just support .sdkrc?

[helpermethod]

This is how the output with two entries looks (one for Java and one for Maven).

[marc0der]

@helpermethod that looks great! Only supporting an sdkman descriptor does make most sense to me too tbh. I would call it .sdkman, as it is not an rc file in Unix parlance and also does not live in the user's home folder.

It would also be great to add some test for this new feature.

[EugenMayer]

.*rc files are like .npmrc rather have the character to be searched the tree up and not living in the home folder only ( IMHO ).

Depending on how this is understood, means "if no .sdkman then take the configuration from the home folder" this could be named .*rc.

I understand that this is about configuring more then just the java version and a like the idea - on the other hand i will miss the .java-version support way of doing this, since i expect developers to look for .*-version in their project ( for whatever language ) to understand what is required. But at least .sdkman / .sdkrc / .tool-versions or whatever you guys pick will have the same ( rather more ) capabilities, so maybe this is just convinience ( but convinience the IDE will understand ).

I expect e.g. IntelliJ to rather support .java-version then a specific .<sometool> since they are not interesting in understand "all the env to SDK tools out there" but rather "what version is expected, agnostig" - i have never seen .tool-versions yet, but that could just be me

[helpermethod]

@marc0der Because there is already a directory .sdkman in the HOME directory, I'd rather name the file .sdkmanrc (.sdkrc may be too vague).

This makes it clear for a user after checking out a project that this is a RC file for a tool called sdkman.

I agree that it goes against the original intent of *-rc files but nowadays these are pretty commonplace as a local configuration file (think .bowerrc, .nvmrc, .jshintrc) so the *-rc ending should be okay.

Another question:

Should the sdk env command just call use, or should it also install the missing tools?

Currently it checks the existence and installs them but I wonder if it would make sense to split these steps.

Something like

sdk env -> just call use for each tool
sdk env install -> install the missing dependencies

[marc0der]

@helpermethod that makes perfect sense so let's go for .sdkmanrc then.

Regarding all the implementation details, how about we move to the cli-development slack channel to discuss it there?

[marc0der]

One outstanding bit we need to implement before closing this issue is config file generation using the env command.

[helpermethod]

Closing this issue as the last missing part has been fixed by #730.

[marcphilipp]

@helpermethod I think you forgot to actually click on "Close". 😉

... and you probably meant to reference #730. 🤔

[helpermethod]

@marcphilipp Thanks, now the PR is referenced instead of the issue.
@marc0der Can we close this, or do we need a release first?