Change recommendation: include generated cabal files

[snoyberg]

For details of the proposal, see the blog post: https://tech.fpcomplete.com/blog/storing-generated-cabal-files

If you are in favor of this change, please press thumbs up below. If you are opposed, please press thumbs down. Of course, feel free to include additional comments below.

[gromakovsky]

One problem with this approach that I encountered is that rebases become more painful. We have a repo with many packages, each one has package.yaml and we store .cabal files in the repo. If someone updates .cabal file(s) in master and you update something different in .cabal files in your branch by updating package.yaml and regenerating them (e. g. you both add a new dependency), you will get unnecessary conflicts because hpack adds a line with a hash.

It's not something critical, I just wanted to warn people about this inconvenience.

[cdornan]

I have been getting feedback from non-stack users complaining about repos with no cabal files. From their perspective it is frustrating so I am delighted with this proposal even if it might be a little more inconvenient. N retrospect Cabal files form the basis of the package system so it is better to include them directly.

[snoyberg]

OK, I'm going to move ahead with this. Thanks for the responses all. Closing as the discussion is done, will be merged to master fairly soon.

[simonmichael]

Agreeing with gromakovsky that this can very often cause conflicts and pain when merging/cherry-picking/switching branches/trying different stack/hpack versions. I think it's worth changing hpack to fix this - if you agree, consider helping sol/hpack#380.

[ulidtko]

Hi! Let me just describe one failure mode collateral from this change. Hopefully, it'll make searching for it easier and speed up resolutions. No response required.

First, the error message:

2020-07-30 10:18:19.050984: [error] Aeson exception:
Error in $.packages[19].completed: failed to parse field 'packages': failed to parse field 'completed': Could not parse a UnresolvedPackageLocationImmutable from: Object (fromList [("size",Number 294200.0),("url",String "https://github.com/private-company/vendor-fork-redacted/archive/fcbaf261368b7f63708351fb1b04eb7f5f0793a3.tar.gz"),("name",String "vendor-fork-redacted"),("version",String "0.9.1"),("sha256",String "54974f6f9851376292cb6f081eef2cd907396899a04af5776da2d2cc45e80fc6"),("pantry-tree",Object (fromList [("size",Number 5039.0),("sha256",String "bc3f1c77c2797f0d0915f5ffff38d5e3cf8cdc613507fe1ace9463bc2492aafc")]))])

Now the cause. In my case, local-development Stack v2.3.1 has produced unintended change to stack.yaml.lock which wasn't understood by Stack v2.1.3 on CI:

@@ -154,9 +140,6 @@ packages:
 - completed:
     size: 294200
     url: https://github.com/private-company/vendor-fork-redacted/archive/fcbaf261368b7f63708351fb1b04eb7f5f0793a3.tar.gz
-    cabal-file:
-      size: 4079
-      sha256: a24d964776e360d0545500c8b28ec254aa323fdf28fa55692a282a25b6ac652c
     name: vendor-fork-redacted
     version: 0.9.1
     sha256: 54974f6f9851376292cb6f081eef2cd907396899a04af5776da2d2cc45e80fc6

Reverting this unintended change fixes the error (as well as updating Stack on CI).

The error reporting could perhaps be better; but this behavior change is well-documented on the ChangeLog. Hope that helps