Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Eisfunke opened this issue Sep 30, 2019 · 4 comments

Comments

@Eisfunke
Copy link

commented Sep 30, 2019

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 added a commit to commercialhaskell/pantry that referenced this issue Oct 3, 2019
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.
snoyberg added a commit that referenced this issue Oct 3, 2019
Fixes #5045. See relevant PR for pantry for more details: commercialhaskell/pantry#7
snoyberg added a commit that referenced this issue Oct 3, 2019
Fixes #5045. See relevant PR for pantry for more details: commercialhaskell/pantry#7
@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2019

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.

snoyberg added a commit that referenced this issue Oct 3, 2019
Fixes #5045. See relevant PR for pantry for more details: commercialhaskell/pantry#7
snoyberg added a commit that referenced this issue Oct 3, 2019
Fixes #5045. See relevant PR for pantry for more details: commercialhaskell/pantry#7
snoyberg added a commit that referenced this issue Oct 3, 2019
Fixes #5045. See relevant PR for pantry for more details: commercialhaskell/pantry#7
@Eisfunke

This comment has been minimized.

Copy link
Author

commented Oct 9, 2019

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

@qrilka

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2019

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

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.