-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Most concerning problem is that the ghc of the dev-enviornment, and test enviornment are not necessarily synced up with the ghc of the release.
This is because we have to specify the ghc version separately in the stack.yaml file, while the one for release, we get it (at the moment) implicitly from nixpkgs. A half-way fix would be to be use the explicitly defined haskell package set in the release.nix file.
It's a halfway fix, because we have to update the ghc version in 2 places, it's still error prone.
Not only this is a halfway fix, but also quite awkward to implement due to how we have arranged our nix files to accomodate stack.
- The unusual way of specifying
haskellPackagesas a dependency for ourvaultenvpackage - How we have a separate expression for specifying haskell dependencies
If we are going to go ahead with this fix, then we should use it as a chance to move to the simpler cabal based setup, something like we've seen @robbert-vdh do for an icepeak release.
This can fully fix the ghc syncing issue, simplify the nix files, simplify the haskell build process, and also pave the way to solve these issues:
We can make use of some of the code changes from this PR (it updated the nixpkgs pin) #140