Haskell devshell template #39
Conversation
There was a problem hiding this comment.
I'm not completely sure why a Haskell template contains shells for Erlang and Clojure.
That being said, I'd say this isn't a particularly good default for a Haskell dev shell. First, you probably want to use Julien's method for Stack, in order for it to work both on Nixos and non-Nixos. You'll also need the ability to choose the GHC version that you use to coordinate with your Stack snapshot (I'm actually not too sure how to retrieve the default version from Nixpkgs, so that's a good question). You will need nix in the shell as well, because Stack's Nix integration will want it (maybe that's built in, though?)
I came up with a basic shell for Haskell recently, and it looks like this (you can ignore just, and probably git). It is not perfect. For once it doesn't guarantee that the installed Ormolu version and the version linked in the HLS is the same (maybe I should use the direct invocation of HLS, rather than the provided wrapper, I'm not sure what the difference is). In fact, maybe we shouldn't tie the Ormolu version with the GHC version at all! (also the devtool bit is to avoid downloading HLS on CI because it's more than 1GB of closure… but this should be trivial to achieve in Nickel shells, hopefully).
All that to say: getting Haskell right is tricky. I'm not against merging this minimalistic proposal, but I strongly suggest we don't leave it at that, because it's not going to be very useful to many users.
| cabal-install.input | priority -100 = "nixpkgs", | ||
| ghc.input | priority -100 = "nixpkgs", | ||
| haskell-language-server.input | priority -100 = "nixpkgs", | ||
| stack.input | priority -100 = "nixpkgs", |
There was a problem hiding this comment.
Why is the priority -100 and not default?
There was a problem hiding this comment.
I think when we first made the shells we had a stupid issue like the basic NickelPackage contract defines a default somewhere and then we have two conflicting defaults, so we had to make the priority "one layer up, but still easily overridable". I would say that this is orthogonal to the Haskell shell in particular, but in parallel we will definitely revisit this to see what is the issue again and if we can get rid of those pesky -100.
There was a problem hiding this comment.
@aspiwack the file builders.ncl is the library containing all the builders, then in your nickel file you can merge all the builders you want to create your shell.
There was a problem hiding this comment.
@rapenne-s is builders.ncl copied in every template then?
There was a problem hiding this comment.
@aspiwack Getting haskell right is hard that's true (... in general, with or without nix! :P). Happy to implement Julien's wrapper. Regarding the GHC version, the pragmatic approach would be to allow the user to choose what version in a simple way. Then it's up to the user making sure the choosen LTS matches the GHC version (if they use stack).
Would this work for you?
There was a problem hiding this comment.
As soon as the ghc version is overridable, then it's easy to make sure that everything is compatible in the style of my Nix shell above (well, except the Stackage snapshot, but I think this is pretty unavoidable).
There was a problem hiding this comment.
@aspiwack yes, to be ready for FOSDEM we made things easier, we have the rust example containing a script creating all the other templates using the rust as a template itself.
We certainly want something better in the future, but it's still not clear how we want to distribute Nickel-nix to users (or its installation process).
| @@ -0,0 +1,39 @@ | |||
| { | |||
There was a problem hiding this comment.
I came up with a basic shell for Haskell recently, and it looks like this (you can ignore just, and probably git). It is not perfect. For once it doesn't guarantee that the installed Ormolu version and the version linked in the HLS is the same (maybe I should use the direct invocation of HLS, rather than the provided wrapper, I'm not sure what the difference is). In fact, maybe we shouldn't tie the Ormolu version with the GHC version at all! (also the devtool bit is to avoid downloading HLS on CI because it's more than 1GB of closure… but this should be trivial to achieve in Nickel shells, hopefully).
@aspiwack (and others if you are interested) for what it's worth, in Zeus we have done the following: https://github.com/tweag/zeuslogics/blob/274cb50d1f7c63fdf7ac32eabe0b7cf30ab5e16b/nix/default.nix#L54-L63
i.e. use an overlay to retrieve the Ormolu package used by HLS (otherwise we had inconsistent formatting between formatting with HLS and formatting in the CL/pre-commit-hooks.nix).
Courtesy of @amesgen for the trick
There was a problem hiding this comment.
This hurts my brain a little. But thanks for the trick! This sounds quite useful.
There was a problem hiding this comment.
it doesn't guarantee that the installed Ormolu version and the version linked in the HLS is the same
In which situation can this happen? My understanding was that each haskellPackages set had only one version for each package (barring custom overrides), so haskell.packages.{blah}.ormolu and haskell.packages.{blah}.haskell-language-server should use the same Ormolu version, right?
There was a problem hiding this comment.
Cf the comment in the code snippet I linked above:
Haskell Language Server (HLS) uses a different Ormolu version than the default one, and it's difficult to change it for now.
See haskell/haskell-language-server#411
If you want an example, you can checkout the zeuslogics repo on commit ab9ae47daeff6ac751ca4ba9ee6931a8344b74dd and see for yourself: the ormolu version in the Nix-shell is NOT the same version as Ormolu used by HLS (enable HLS debug logs then look in the logs for the Ormolu version they use). Concretely, formatting the repo with ormolu or with HLS using Ormolu yields different formats, too.
Partially related, starting in HLS 2.3.0.0, I added the possibility to configure HLS to use an external ormolu binary via a configuration flag. For more information, see haskell/haskell-language-server#3771
There was a problem hiding this comment.
Aaah indeed, so “barring custom overrides” is not just a theoretical concern. Thanks for the pointer.
Partially related, starting in HLS 2.3.0.0, I added the possibility to configure HLS to use an external ormolu binary via a configuration flag. For more information, see haskell/haskell-language-server#3771
I've seen that, yes! Hopefully we'll just use that in the future (but the default HLS in Nixpkgs is still 1.something, so it's a bit early unfortunately)
There was a problem hiding this comment.
but the default HLS in Nixpkgs is still 1.something, so it's a bit early unfortunately
Which nixpkgs branch are you referring to? On nixos-unstable the current version is 2.3.0.0+, that's what we use for Zeus.
|
@TaylorEwtonQ please refrain from posting bot comments on this PR, or any nickel-lang repository. Otherwise, I'll unfortunately have to report your account. |
|
Closing in favour of #67 |
I basically copied the rust template and changed the inputs. Do we need to keep all
builders.nclin sync?Let me know if I am doing it wrong.