Hashes in existing projects break with new Dhall version

[f-f]

I setup a project with the currently released Spago version:

$ spago version
0.6.3.0

$ spago init
Set up a local Spago project.
Try running `spago install`

Then I upgrade Spago to the latest master, and if I try to install, it fails:

$ spago version
0.6.4.0

$ spago install
spago:
↳ ./packages.dhall
  ↳ https://raw.githubusercontent.com/spacchetti/spacchetti/20181209/src/mkPackage.dhall sha256:8e1c6636f8a089f972b21cde0cef4b33fa36a2e503ad4c77928aabf92d2d4ec9
This decoded version is not supported: 4.0.0

What happened here?
In this commit we upgraded to the latest Dhall version (1.19 → 1.20), which also upgraded the Dhall language version (4.0.0 → 5.0.0), rendering the hashes in the project file non-compatible with the new version, which cannot decode them.

There is already an issue open about a related problem: dhall-lang/dhall-lang#335

Once the fix will be implemented in Dhall it will be easy to "upgrade the clients" if the hash of the expression is the same (but the version unsupported), I'll investigate if in the meanwhile we can patch it nicely and "autoupgrade" the projects

[f-f]

@Gabriel439 would you have any suggestion on how to go about fixing this? The goal here is to migrate existing configs to the new version/hashes as automatically as possible.

I considered the following flow:

• if there's a hash and a cache hit, try to decodeWithVersion it. If it's an old version substitute the new current version of the standard in the Haskell-CBOR Term and try to decode anyways.
• If this last decoding is successful, refreeze the import with the current standard version

Would this makes sense?

I took a stab at a modified version of Dhall.Binary.decodeWithVersion, but Dhall.Binary.decode is not exported (and I'm not sure it'd be a good idea to export it?), so I'm unsure how to proceed

[Gabriella439]

@f-f: I think I just need to hurry up and standardize dhall-lang/dhall-lang#335. That seems like the correct solution to this