Update nixpkgs and GHCs for cabal / stack, test with PG 17

[wolfgangwalther]

Update and align everything. Let's see which parts pass and which don't.

[wolfgangwalther]

The macos build is failing, but it was passing before already once. I can't built it locally and push to the cache.. so I will just run it on main to have that happen and will possibly restart it if necessary. Should be good after running through once.

[steve-chavez]

Q: I thought I saw GHC 9.10.1 in this PR before, why was it removed? Something broke?

I was hoping to do some experiments with Linear Types, GHC 9.10.1 added support for using it with let/where (ref).

[wolfgangwalther]

Right, the dependencies are not up2date to support it, yet.

The first one that broken was Protolude - didn't get any further than that. Since there is not much activity upstream, we might need to consider switching to a different Prelude replacement.

[steve-chavez]

After this PR, I got the following error locally:

$ postgrest-with-postgresql-16  -f test/spec/fixtures/load.sql postgrest-run

...
Error: [Cabal-7159]
Latest known index-state for 'hackage.haskell.org' (2024-05-17T23:41:49Z) is older than the requested index-state (2024-11-10T13:08:54Z).
Run 'cabal update' or set the index-state to a value at or before 2024-05-17T23:41:49Z.

Running cabal update manually fixed the issue. I guess this is because of the cabal.project.freeze file?

[wolfgangwalther]

Running cabal update manually fixed the issue. I guess this is because of the cabal.project.freeze file?

Yes, correct. I added cabal update to everything that build or tests in CI, to do that automatically, but I guess I might have missed some tools that are only run locally.

[steve-chavez]

I think we discussed this before, but couldn't we just delete the cabal.project.freeze? I don't recall why we needed it if we have Nix.

[wolfgangwalther]

I think we discussed this before, but couldn't we just delete the cabal.project.freeze? I don't recall why we needed it if we have Nix.

I think this would silently pull in new dependencies for cabal-based builds, which we still do. This makes CI not reproducible anymore. Not sure whether that was the original reason why it was added, though.

[develop7]

I think this would silently pull in new dependencies for cabal-based builds, which we still do. This makes CI not reproducible anymore. Not sure whether that was the original reason why it was added, though.

It's exactly the reason I've introduced it in #3004. Should've added a comment there too, though.

Also I wonder if I could fix these more explicitly by introducing upper bound in cabal.project

[wolfgangwalther]

It's exactly the reason I've introduced it in #3004. Should've added a comment there too, though.

Thanks for linking that discussion again. There was a suggestion of tying the index-state and the nixpkgs version together. I think this makes sense - in principle. I already tied the nixpkgs version together with docs/requirements.txt for the readthedocs.io build in here.

For hackage that's not as easy. First of all, a certain date for nixpkgs doesn't mean it had already pulled in that date of hackage - so the dates are certainly different. Furthermore, the haskell packages available by default in nixpkgs are actually based on stackage LTS, not hackage.

In any case, the big goal is to eventually do everything in nix - and we have moved a lot closer to that goal within the last couple of months.

Also I wonder if I could fix these more explicitly by introducing upper bound in cabal.project

I think this is a lot harder to maintain. IMHO, we'd ideally not have any upper bounds in cabal.project. Or at least no upper bounds, when we are compatible with the latest version anyway. I mean, why would we? Can we tell in advance whether a new version will be compatible or not? Certainly not.

Imho, we should only have upper bounds if we know a newer version is not compatible. Example: fuzzyset, where we know 0.3.x is not compatible anymore.