Feature: support loading `.sdkmanrc` from a parent project (if exists)

[alvarosanchez]

Sometimes I want to use the same JDK for a set of projects, so instead of adding .sdkmanrc to each of them, it will be useful to allow adding only one in the parent directory of all those projects.

Link to the Slack discussion for more context: https://sdkman.slack.com/archives/CJK9DMV6V/p1657181707248489

[jamesdh]

direnv does this via the source_up stdlib command, and I'm guessing it'd be fairly easy to borrow from them.

Modifying sdk env install so that it can take a path argument instead of expecting it to be in the current directory would also go a long way towards solving this.

[jamesdh]

Related to (and discussed in) #756

[gavvvr]

I second this feature request. Having a monorepo with a bunch of microservices, I would not like to copy and commit .sdkmanrc to each service's sub-directory.

For me and some other people the lack of support for this even seems counter-intuitive. Probably, because I also use asdf to manage non-JVM tools and the similar parent config file for asdf (.tool-versions) is respected by default:

Whenever .tool-versions file is present in a directory, the tool versions it declares will be used in that directory and any subdirectories.

So, I think that the closest parent .sdkmanrc should be respected too. Probably, not by default, but at least with an option to enable this behavior.

I've seen the performance concern from @helpermethod in 756:

That would mean it would recurse on every directory change and probably re-executing the one found in $HOME multiple times when traversing directories.

I agree, the sdk use is noticeably slow for SDKMAN, but I do not think it should be executed on each directory change if the version of the tool does not need to change (i.e. I switch between different microservices of the same monorepo sharing one common .sdkmanrc, no action is required, no need to invoke sdk use).

Continuing to compare with asdf: it not only respects it's parent config file by default, but also works very quickly in any situation (even if the version of the tool should be changed). So, probably there is also a room for improving performance of sdk use (at least there is the example of the tool which performs similar job very quickly)

[rakus]

I just installed sdkman a few hours ago and expected it would work as described in this feature request.

[jamesdh]

FWIW, you can work around this issue by simply symlinking the root level .sdkmanrc everywhere it's needed.

[bas-kirill]

bump

[Ed42]

This is sufficiently bad that I've had to disable the otherwise useful auto-env feature. Any ideas on an ETA for a proper fix?

[barspi]

I came here to ask for [what I think is] this feature.

Specifically, what I would like is that if I use the explicit command sdk env in a certain directory, and the .sdkmanrc file does not exist, it would look it up in the parent dir, traversing the tree up (all the way to the root?)

This is, for example, how git works (searching for the hidden .git directory up the tree)

if you don't want to change the default behavior (for backward compat) I could even live with one of these options

• a flag in ~/.sdkman/etc/config such as sdkman_auto_env_lookup
• a command line param such as sdk env lookup

[helpermethod]

I came here to ask for [what I think is] this feature.

Specifically, what I would like is that if I use the explicit command sdk env in a certain directory, and the .sdkmanrc file does not exist, it would look it up in the parent dir, traversing the tree up (all the way to the root?)

This is, for example, how git works (searching for the hidden .git directory up the tree)

if you don't want to change the default behavior (for backward compat) I could even live with one of these options

• a flag in ~/.sdkman/etc/config such as sdkman_auto_env_lookup
• a command line param such as sdk env lookup

This is exactly the idea.

[mkurz]

Would be awesome if this would become reality. If there are concerns regarding performance or change of the defaul behaviour, just add it as config flag which is disabled by default.