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

Upgrade to GHC 8.8 and Dhall 1.35 #685

Closed
f-f opened this issue Sep 7, 2020 · 8 comments
Closed

Upgrade to GHC 8.8 and Dhall 1.35 #685

f-f opened this issue Sep 7, 2020 · 8 comments

Comments

@f-f
Copy link
Member

f-f commented Sep 7, 2020

See dhall-lang/dhall-haskell#2031

@f-f f-f changed the title Upgrade to the latest Dhall Upgrade to GHC 8.8 and Dhall 1.35 Sep 13, 2020
@f-f
Copy link
Member Author

f-f commented Sep 13, 2020

I gave this a shot, and apart from the fact that this will require us to rework the CI (possibly porting it to GitHub Actions) it looks like dhall-1.33 carries a change that it's pretty breaking for us: language keywords cannot be used anymore as record keys, see dhall-lang/dhall-haskell#1801.

In our case this means that a new version of Spago using the latest Dhall (1.35 at the time of writing) will not be able to parse package sets that contain the package assert (because that's a keyword).
I already patched package-sets so that all the new sets correctly quote the assert package: purescript/package-sets#692

Of all the possible solutions to "we want to use the new Dhall but also parse old package sets", there is only one that is completely transparent to the users: write a script that goes through all the releases of package-sets, downloads the package-set file that Spago imports, patches it in the same way as my PR above, and reuploads it in the release.

This is transparent to the users because the hash (which we use to ensure that the imported set does not change) is unaffected, as the Dhall binary representation for "record key" and "quoted record key" is the same.

@hdgarrood
Copy link
Contributor

Patching old releases like that sounds okay to me. Why would it require us to rework the CI, just out of interest?

@f-f
Copy link
Member Author

f-f commented Sep 13, 2020

@hdgarrood the Travis build for Linux uses a docker image to have a decently fast cache. To upgrade the GHC version I'd have to upgrade it in there and rebuild the images, etc. I don't really feel like it's worth spending any more time on fixing Travis at this point, when GitHub Actions is faster, better integrated, etc.

@f-f
Copy link
Member Author

f-f commented Sep 17, 2020

Heads-up @nwolverson: we'll need to apply the script I described above also to the releases of purerl/package-sets (tests are failing on my local Spago branch with the new Dhall because it cannot parse the purerl package set that we have in a test)

@f-f
Copy link
Member Author

f-f commented Dec 3, 2020

@nwolverson @csicar @andyarvanitis : I am about to cut a new version of Spago, which will not work on all the previous package sets containing a package called assert (see above discussion for reasons why).
We were able to fix this in a transparent way for the main package-sets repo thanks to a script that @JordanMartinez put together, here: https://github.com/JordanMartinez/fixPackagesDhallFiles

The script just goes through the releases of the package-sets repo and updates the packages.dhall file when needed. I'd recommend running the same script on the custom package-sets you have for the alternate backends, in order to be compatible with the upcoming Spago 0.18 release (I'll wait a couple more days before cutting it). Note: the updated files are backwards compatible.

@f-f
Copy link
Member Author

f-f commented Dec 3, 2020

Also I believe this can be closed, as it was fixed in #695

@f-f f-f closed this as completed Dec 3, 2020
@nwolverson
Copy link
Collaborator

With minimal tweaking ran the script against recent purerl package sets - thanks @JordanMartinez for the work in there, @f-f for the coordination

@JordanMartinez
Copy link
Contributor

Glad to here it went smoothly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants