Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
stack.yaml.lock file portability over hpack versions with extra-deps #5045
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
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:
But the docker image
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?
For an example of this bug, see commercialhaskell/stack#5045. Problem: pantry was including the hash of generated cabal files in lock files, and then when newly generated cabal files (based on new hpack versions) mismatched, it considered it a different package. Solution: do not store the hash of the generated cabal file, but instead of the source hpack file.