stack-setup-2.yaml gets out of date

[judah]

The stack-setup-2.yaml file occasionally gets out of date -- in particular, every time there's a new version of GHC:

$ pier build haskell-src-exts
Error when running Shake build system:
* Library haskell-src-exts
* GHC StackageGhc, version 8.4.3, built-in packages containers, ghc-prim, ghc-boot, ghci, template-haskell, terminfo, ghc-boot-th, binary, deepseq, base, filepath, hpc, ghc, rts, unix, array, process, pretty, transformers, bytestring, directory, integer-gmp, time
Couldn't find GHC version8.4.3

To fix it, currently you need to delete ~/.pier/downloads/stackage/setup/stack-setup-2.yaml and then run pier clean.

Other downloaded files (e.g. LTS versions, package tarballs) have version numbers in their names (and are in theory supposed to be frozen) so are less vulnerable to this issue.

We'll have to look into what Stack does. Some possible workarounds:

• At minimum, we we should be able to give a better error message when this occurs (and potentially not require an explicit pier clean).
• We could download it for every (non-clean?) build, and save it somewhere (with the git hash in its filename). Unfortunately this breaks "airplane mode".
• We could provide an explicit command (maybe pier setup or pier refresh?) that "invalidates" it, i.e., causes pier to re-download it again the next time. And, perhaps, mark downloads by whether or not they need to be re-downloaded.

[bergey]

Is it safe to assume that this yaml file is append-only? That is, any entry in the local copy is valid, but the server copy may include more entries that we don't yet know about. Then we can handle the common cases by checking the local copy first, fetching the remote if we don't have the requested key locally, and fetch at most once per invocation. I think this is how stack handles the Hackage index.

If this seems like the right approach, I'm happy to take a stab at implementing it.