Use internal nix-tools and cabal-install in call-cabal-projet-to-nix

[michaelpj]

This is mostly just to kick of discussion, this might well be the wrong thing to do.

Recently, I tried bumping our compiler version. And, as usual, I had to wait a long time before I could eval, because I had to build the nix-tools and cabal-install for the new compiler version.

But: why? This is the big thing eval-time dependency, so always using a version that should be cached is a big win. I think the main argument is what @hamishmack said in #738:

Less overhead on macOS where dynamic linking pulls in the compiler used for nix-tools and cabal-install.
Yes that is my main concern. On macOS it is likely build or download a whole extra GHC. If the user tries to solve that by passing in your own nix-tools to cabalProject but then everything in the cache that depends on nix-tools does not match.

I don't have a counter-argument to this except to say that the prize (making it much more likely that eval-time deps are cached) seems big enough that it's worth bearing some coost.

[hamishmack]

I think this comes back to figuring out how we should support old versions of GHC. For instance if the change had required a rebuild of GHC (not just nix-tools) then ghc883 would also have been missing from the hydra cache.

I quite like the idea of just having ghc86, ghc88 and ghc810 instead of including the patch release number (since we already apply patches and you could argue that ghc884 is just ghc883 with another patch). I'm not sure if that is a good idea though.

For now I think #817 and #821 can fix the caching while avoiding the macOS issue.

#817 will fall back on ghc865 when there is no materialization for nix-tools or cabal-install (currently we have materializations for 865, 883, 884, 8101 and 8102).

#821 includes the haskell-nix roots for 883 and 8101 in ci.nix.

[michaelpj]

I quite like the idea of just having ghc86, ghc88 and ghc810 instead of including the patch release number (since we already apply patches and you could argue that ghc884 is just ghc883 with another patch). I'm not sure if that is a good idea though.

That's true! So I guess it was a bit of an odd situation where I didn't hit a GHC rebuild but I did hit a nix-tools rebuild. Actually, that's quite odd - we cache the roots for every compiler version, right?

I quite like the idea of just having ghc86, ghc88 and ghc810 instead of including the patch release number (since we already apply patches and you could argue that ghc884 is just ghc883 with another patch). I'm not sure if that is a good idea though.

I'm not sure, since sometimes people do want to use an earlier patch release due to issues in later ones. Also if you're using stack-to-nix, you'd like to use exactly the compiler specified by the snapshot.

[hamishmack]

we cache the roots for every compiler version, right?

Only the ones in ci.nix and ghc 8.8.3 and 8.10.1 were no longer included (#821 adds them back).

[michaelpj]

Okay, fine, I'm convinced this won't help (since now nix-tools uncached <=> ghc uncached <=> you're screwed anyway).