Changing hackage metadata can invalidate ~/.stack cache, thus making builds non-reproducible

[bitonic]

Consider the following case:

• Project foo depends on bar-1.2.3 in its extra-deps.
• Currently bar-1.2.3 is at revision 1 on Hackage, with certain version bounds that work for foo.
• The metadata for bar-1.2.3 is changed on Hackage to version bounds that do not work for foo anymore. Now bar-1.2.3 is at revision 2.
• If I currently have bar-1.2.3 cached in my ~/.stack, I don't notice the breakage at all (since I keep using revision 1), but users getting a fresh Hackage index (I think it's called that way) will (since they'll use revision 2).

The solution to this is to fix the Hackage package revision, either by defaulting to the first revision, or through some other UI.

[Blaisorblade]

I agree stack should fix this issue even before it ever triggers, however unlikely; but did it also happen in practice? I'm asking to judge urgency.

[mgsloan]

Yeah, this is what the SHAs thing is for, it means that the stackage snapshot specifies a specific revision. We don't support it for extra-deps, but once implicit snapshots are implemented, it'll probably become possible.

In practice, hackage restricts the edits you can make. If these edits break the build, then you can always use --allow-newer to ignore the constraints.

[Blaisorblade]

In fact, I learned that the issue has been discussed to death in
haskell/hackage-server#52 (comment) and
haskell/cabal#2222 (showing breakage from changes to bounds).

However, while I'm in favor of allowing to fix revisions, I'm not sure I'd always want to. What happens if some version combination turns out to be buggy and is forbidden through cabal edits? Or is that better handled by deprecations?
My standard example is adding a bound like this retroactively to fight a 10x performance regression.

And in most cases, revisions upgrades will not break working stack.yaml, only make more ones valid (though haskell/cabal#2222 might be a counterexample).

Or in other words: updating to a newer version of stackage takes some work, and I don't want that to increase because I have to specify revisions.

I think this also requires an extra index on all-cabal-hashes (unless configurations mention revisions by SHA rather than revision number, which is only maybe OK).

[mgsloan]

Right, the specification of revisions comes with the snapshot. It is highly unlikely that they will ever be mandatory for stuff like extra-deps, just recommended if you want that last bit of reproducibility.

[seagreen]

Just an idea -- we could go with a stack.freeze file.

It could be generated when you build a project that has extra-deps. That way we can get reproducibility back without messing up the convenience of not having to specify hashes in stack.yaml:/

EDIT: To be clear about what I mean, stack.freeze would just contain a mapping of packages-name --> cabal file hash.

[snoyberg]

We have lots of work in this direction with Pantry. See also #4288 for next steps.