search

typelevel / typelevel-nix

Development tools for Typelevel projects
Apache License 2.0
109 stars 12 forks source link

Basic questions #17

Closed cquiroz closed 2 years ago

cquiroz commented 2 years ago

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-shell

Maybe this should better be in a Discussions section?

rossabaker commented 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.

cquiroz commented 2 years ago

Cool the http-client example helped me. What should the metals command do?

cquiroz commented 2 years ago

Should you be able to specify the node version?

rossabaker commented 2 years ago

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.

cquiroz commented 2 years ago

It seems fine, I asked for the odd case (like facades) where we still use some old node version

rossabaker commented 2 years ago

I'd welcome a PR. It would look a lot like the jdk option.

cquiroz commented 2 years ago

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?

cquiroz commented 2 years ago

I guess I should close this

rossabaker commented 2 years ago

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.