Closed cquiroz closed 2 years ago
One significant difference is that this is based on Nix Flakes, which came out experimentally in Nix 2.4. That version of Nix really should have been called 3.0-beta. It's a pretty big leap, and to use flakes, you need to turn on the experimental flag.
Flakes have output attributes, that include devShells
. They are typically entered via nix develop
. A flake can be addressed straight from GitHub, and we can provide named devShells
, which look like a URI anchor. So nix develop github:typelevel/typelevel-nix#library
gets you into the library
shell (JDK8) and nix develop github:typelevel/typelevel-nix#application
gets you JDK17.
Flakes are also composable, so projects can supply their own devShell, and customize what they like. An interesting example is http4s-jdk-http-client, which requires JDK11. If you clone that project, it provides a default devShell, and you can just do nix develop
.
If you prefer the older nix-shell
, @gvolpe added a bridge for that to this project. It's not quite as convenient to pull remotely, but also keeps you more in "mature Nix" territory. The README has an example of that usage.
Cool the http-client example helped me.
What should the metals
command do?
Should you be able to specify the node version?
Metals is added to your $PATH so it launches with the same JDK as the project compiles with. I was having problems running tests, because I was compiling with one Java version, Metals was running with another, and I got link errors on the java.nio stuff. You should need to call it directly, and perhaps we should remove it from the MOTD.
A configurable node package would be good. I have suffered because the default node in nixpkgs was old and made http4s tests run for over an hour, and the one that's there works a lot better. I don't do enough with node to know whether 16.13.2 is reasonably current.
It seems fine, I asked for the odd case (like facades) where we still use some old node version
I'd welcome a PR. It would look a lot like the jdk
option.
Sorry another dumb question I guess. If you'd like to provide custom jvm or sbt options should they live as jvmopts
or sbtopts
or should they be integrated into shell config. I guess you could generate them as well?
I guess I should close this
Sorry, I've fallen behind on my notifications...
I'd probably do that with environment variables, which devshell can set per project. There's an example (not related to this project) here. But if it's per-project, you might as well just put an .sbtopts
in the directory. I think it would only be useful for shells you bring ad hoc to other projects.
Hi
sorry to ask basic questions. I'm trying to learn nix and use it to setup my shell environment for some of my projects. Some use jvm 8 some 17, many scala.js thus node
I set a basic system following https://github.com/gvolpe/sbt-nix.g8 and I was a bit wondering how is this different and also trying to learn how to use
typlevel-nix
with nix-shellMaybe this should better be in a
Discussions
section?