Revert hpack version comment from 0.37.0 to 0.36.0

[ceedubs]

These were changed by #5522. It doesn't seem like it should be a consequential
change, but the nix build seems to be treating the following as a fatal error
that breaks the build:

unison-runtime.cabal was generated with a newer version of hpack, please upgrade and try again.

[aryairani]

We use hpack to generate our .cabal files from package.yaml files. When we do a stack bulid, it checks if the package.yaml files have changed relative to the corresponding .cabal file. If it has, and if the corresponding .cabal file wasn't created by a newer version of hpack than the one currently running, hpack will update the .cabal file correspondingly to the change in the package.yaml file.

Therefore, we all kind of need to be on the same version of hpack. (Our hpack is embedded into stack as a Haskell library, so the same version of that library.) If we don't, then .cabal files can get out of sync like this. Usually it's not a problem in CI, because when hpack refuses to update the .cabal file because its version is not new enough, the intended .cabal file has probably already been checked in too, and the build just uses that, possibly with a warning I'm not sure.

The problem is when one person edits a package.yaml and generates the .cabal file with a newer version of hpack, and then someone else comes along and edits the package.yaml, when we try to regenerate the .cabal file with the second person's changes, it's blocked.

We have a mix of 0.35.0, 0.35.2, 0.36.0, and 0.37.0. It's fine to have a mix, as long as whenever you edit a package.yaml you have a same or newer version of hpack than the one that was used there last. So when some people jump their versions ahead of other people's, then we run into trouble. If we all update a the same time, then it's fine.

I'm guessing the nix flake uses 0.36.0, whereas the latest version of stack in homebrew uses hpack 0.37.0. The latest version of standalone hpack in homebrew is 0.38.1 🤯

Can we update the flake to use 0.37.0? Otherwise try to get everyone to use the nix flake.

[aryairani]

^ @ceedubs :)

[ceedubs]

@aryairani the short answer is that the hpack version is tied into the haskell.nix version that we depend on, and when I try to update our haskell.nix version I run into some other issues. I imagine that if people really want to update to hpack 0.37.0 then I can figure out a way. But if it's just that one contributor happened to be on that version, I'm not sure that it's worth figuring it out and making other ucm contributors figure out how to get there.

[aryairani]

@ceedubs It's a little more complicated because people are installing stack, and that has a somewhat arbitrary version of hpack built in, so it's hard to force people to use a particular version. So it's not that people really want to update to hpack 0.37.0, they just have it despite built into their stack without caring what version they have. I don't think there's a one-to-one guarantee either that if I have a certain version of stack that I'll have a certain version of hpack. Other factors in the build environment determine which hpack is included.

I think Travis had had us building a custom stack with nix with a particular hpack version, but I'm not sure how that worked.

[ceedubs]

FWIW the current flake doesn't choose a particular hpack version; it just asserts that the one that we get from haskell.nix is the expected version. Notably that version is 0.35.2 which is neither 0.37.0 nor 0.36.0, so I'm not sure why 0.37.0 is an issue but 0.36.0 is not.

At some point I can try to play around with updating the version of haskell.nix that we depend on. But I don't really know how to go about it if there's not really a target version of stack/ghc/hpack that we are aiming for. Ideally whatever we are using in CI?

[aryairani]

0.36.0 vs 0.35.2 will also be an issue potentially, it just depends on the exact order of operations. I actually don't understand how this PR fixed anything (apart from avoiding a warning).

The target version is just whatever we can get all the developers onto most easily; though I don't know what that is. Or else we just deal with the occasional hiccups. Or we could exclude all the .cabal files from the repo and just let them be regenerated by whatever version of hpack, which would probably be fine because I doubt we're using any cutting edge features. Might be annoying to the non-stack users but maybe they'd forgive us.

[sellout]

I think the usual issue with

unison-runtime.cabal was generated with a newer version of hpack, please upgrade and try again.

is that the package.yaml changed, but the updated unison-runtime.cabal wasn’t committed. So, every build with stack first regenerates unison-runtime.cabal, which works fine … as long as you have an hpack that isn’t older than the one named in the Cabal file.

It seems like the easiest way to achieve this currently is to build, and then do a git diff to make sure nothing has changed.

@ceedubs is right about the way hpack is handled in Nix currently. More generally, there is nix/versions.nix that contains all of our “recommended” tool versions (some via imported JSON). These are then managed in a couple different ways. On the Nix side, we either check that the installed version matches the recommended version (done for hpack & stack) or we tell haskell.nix to install the recommended version explicitly (done for cabal, hls, & ormolu). In VS Code, we pin the subset of nix/versions.nix that comes from .vscode/settings.yaml (so, cabal, hls, & stack). Outside of those two toolchains, we don’t have any control.

This most frequently seems to cause issues with hpack & ormolu.

Or we could exclude all the .cabal files from the repo and just let them be regenerated by whatever version of hpack, which would probably be fine because I doubt we're using any cutting edge features. Might be annoying to the non-stack users but maybe they'd forgive us.

This isn’t the worst thing, especially since Cabal isn’t officially supported. If we made this change, then maybe also add a script to run hpack across the repo and mention it in the docs for Cabal users?

Another way to help on the hpack side is just to have our recommended version be pretty new, because then it will be contributors who use other versions that see errors like the above at the time they edit package.yaml, rather than those using the recommended version seeing it when building a clean checkout.

I think I can update #5486 to make things a bit better. For one, hpack can be updated to at least 0.37.0. And I think it can be switched from grabbing the default Nixpkgs version to having haskell.nix install the requested version, which might allow us to push it newer – say to 0.38.0.