typelevel-nix
typelevel-nix copied to clipboard
jre used by scala-cli
https://github.com/typelevel/typelevel-nix/blob/27b58dea50fcd1d185df9ea3024bb2e914dce0b4/modules/typelevelShell.nix#L39
I am new to Nix and Scala, so please excuse me if I got this wrong.
It seems to me that the scala-cli
is built without overriding the jre
attribute, and thus it defaults to the one from nixpkgs, which in my case currently happens to be zulu19.30.11-ca-jdk-19.0.1
. So by using this flake, I have both jdk-19
and jdk-17
installed. I couldn't think of why scala-cli
cannot use jdk-17
. If this isn't an oversight, I'd appreciate it if someone could help me understand why this flake needs two different jdks. Thanks!
I thought this would be an easy fix, but see #86. We can add another config option with a smarter default, but the idea of "one JRE for the whole devshell" doesn't work when SBT needs to be on something below Java 17.
Thank you for your quick response! Now it makes sense why scala-cli
might have been left out of use the chosen JRE.
I like your suggestion -- even though one JDK would have been ideal, multiple JDKs only when necessary would be a good (enough) option.
If I make it refer to the default, it works great for application
and can be overriden in library
. But anyone who creates their own shell, like for a Java 11 library, gets a crash at startup until they set this new option.
Alternatively, I can just pin scala-cli to jdk17, which works great... until someone creates a shell with a default > 17 and wants them to align. I don't yet have a clean way to detect the version of the default JRE and override it by default if and only if it's too old. 🤔
here's how I handled it in devenv: https://github.com/cachix/devenv/pull/311/files#diff-741cdd590957888463a214f5325a8cdb5c1aba2da3c4d2c80d29474216586487R33
and how it works: https://github.com/cachix/devenv/blob/main/examples/scala/devenv.nix