stack.yaml.lock file portability over hpack versions with extra-deps

[Eisfunke]

I have a Stack project with extra-deps. I build it, it works fine, I check it into version control. As told in the lock file docs, I check the stack.yaml.lock file in as well.

That's no problem until I try to build the package on a machine with a different hpack version.

On my home machine I have hpack 3.2. Because of that the cabal file of the extra-deps repo contains "by hpack version 0.32.0" in the header and the hash of that cabal file is written into the lock file:

packages:
- completed:
    cabal-file:
      size: [size]
      sha256: [hash of the whole cabal file, not the same as the hash saved in the header of the cabal file itself]
[...]

But the docker image fpco/stack-build/lts-14.7 for example runs hpack 0.31.2, so when building there the cabal file for the extra-dep is generated with that, contains "by hpack version 0.31.2", therefore has a different hash and the build aborts with

Mismatched package metadata for Repo from [extra-dep repo], commit [commit hash]
Found: [package] with cabal file [cabal file hash with hpack 0.31.2] and tree [tree hash]
Expected: name == [package name, fits], version == [package version, fits], tree == [tree hash, fits], cabal file == [cabal file hash from the lock file generated with hpack 0.32]

Funny thing is: the hash in saved in the headers inside the cabal files are identical, it's really just the version number in that same headers that breaks it.

I discovered that with a package I'm doing GitLab CI with the aforementioned Docker image on. I could just put the lock file into the .gitignore and let the CI generate its own, but as mentioned, the docs say the lock file can be in source control and should be to ensure reproducible builds, and the same thing would happen outside of CI with other developers simply using another distribution with another hpack version.

I don't think the build should fail just because of different version numbers in cabal files that are otherwise identical? Or is it intentional and I'm just using it wrong?

[snoyberg]

I haven't tested it in depth yet, but I think this PR will fix things: #5049. I'd appreciate if you could give this a try and see if it fixes things.

[Eisfunke]

I tried it out, Stack warns Warning: [lockfile path]: Unrecognized field in UnresolvedPackageLocationImmutable.PLIRepo: cabal-file but builds just fine. Thank you!

[qrilka]

@Eisfunke I think this was resolved by commercialhaskell/pantry@55c943a

[snoyberg]

Thanks for confirming @Eisfunke, I'll merge to stable shortly.