Upgrade to GHC 9.10, bump nixpkgs
#159
Conversation
At least they compile!
This reverts commit d1b6633.
| # Using `hackage-package` will prevent building `ormolu` | ||
| # from interfering with the build plan (incl. incompatible | ||
| # compiler versions) | ||
| o = pkgs.haskell-nix.hackage-package { |
There was a problem hiding this comment.
I've switched the formatter to Fourmolu, for several reasons:
- We use it elsewhere
- It's better than Ormolu
- Even staying with Ormolu will require a large reformatting of the Haskell codebase, so we might as well switch to Fourmolu
I've disabled the CI check for formatting for now. Once the upgrade is in and confirmed working everywhere, I will re-enable it in a re-formatting PR
| author: Sam Balco | ||
| maintainer: [email protected] | ||
| build-type: Simple | ||
| cabal-version: 2.4 |
There was a problem hiding this comment.
I cabal-fmt'd the Cabal files, the inconsistency was bugging me. I can add a formatting check for this in the future re-formatting PR
| , bytestring >= 0.10.10 && < 0.12 | ||
| , containers >= 0.6.2 && < 0.7 | ||
| , cryptonite >= 0.30 && < 0.31 | ||
| , base |
There was a problem hiding this comment.
I decided to get rid of the strict version bounds, again for several reasons:
- We use Nix for this and don't need to involve the Cabal bounds solver again
- This is our practice elsewhere
- We added these version bounds only to appease
cabal sdistfor release to Hackage, but we haven't done a Hackage release in ~2 years. I don't think we even should, since a lot of the project would be very difficult to build outside of Nix - Having these constraints makes upgrading harder
cabal gen-boundsdoesn't help very much
| Left err -> print err | ||
| Right ast -> | ||
| evalExpr defaultEnv Map.empty ast >>= \case | ||
| getArgs >>= \case |
There was a problem hiding this comment.
I tested this executable fairly early on so changed it to avoid head (which emits a warning on GHC 9.10). However, there are unfortunately several other places in the codebase where head is used. I've decided to leave that for another day, as it involves a fairly large refactor (either that or disabling the partial warning, which I think is a good thing and should be left enabled)
| , config | ||
| , ghcOptions ? [ ] | ||
| , profiling ? false | ||
| # Must be of the form: { device = <cpu|cuda-10|cuda-11>; } | ||
| # Must be of the form: { device = <cpu|cuda-118>; } |
There was a problem hiding this comment.
We can only build with CUDA 11.8 now
| @@ -1,17 +1,17 @@ | |||
| final: prev: { | |||
| # Override the default NVIDIA driver with one known to work well with | |||
| # CUDA | |||
| # the V100 GPU | |||
There was a problem hiding this comment.
This has been tested and is working on a V100 GPU
| inherit device cudaSupport; | ||
| }; | ||
|
|
||
| (prev.libtorch-bin.override { inherit cudaSupport; }).overrideAttrs |
There was a problem hiding this comment.
Hasktorch is on a slightly older version of libtorch-bin and Pytorch (2.3.0), hence the overrides
| @@ -27,45 +28,46 @@ | |||
| }; | |||
| }; | |||
|
|
|||
| nonReinstallablePkgs = [ | |||
There was a problem hiding this comment.
IIRC I originally added these only so that Hasktorch would build, back when we first began the Hasktorch integration. However, it seems that it no longer builds with nonReinstallablePkgs specified. Removing it entirely works
|
Just need to fix the |
Bumps haskell.nix flake input to a slightly newer commit than in #159 so that we can use 24.11 as a new stable branch. Also adds a few small changes (adding `hlint` to the shell env, etc...). The new nixpkgs for building images is working (I've confirmed elsewhere). No Haskell changes.
haskell-nixinput to recent commitEverything is building fine, including our CPU/GPU Inferno ML images (tested elsewhere, running on actual EC2 instances). I didn't need to make any changes to the Haskell code for the upgrade, just configuration changes.
NOTE: There are some compiler warnings now that are present on GHC 9.10 but not on earlier versions. I'd prefer not to make a CPP mess of a large number of Haskell modules, so I've left those unaddressed. Once we switch to GHC 9.10+ everywhere, we can fix them.