You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
haskellPackages
as a dependency for ourvaultenv
packageIf 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
The text was updated successfully, but these errors were encountered: