example GitHub workflow for for building Spago statically

[cdepillabout]

Description of the change

wip

Checklist:

• [ ] Added the change to the "Unreleased" section of the changelog
• [ ] Added some example of the new feature to the README
• [ ] Added a test for the contribution (if applicable)

P.S.: the above checks are not compulsory to get a change merged, so you may skip them. However, taking care of them will result in less work for the maintainers and will be much appreciated 😊

[cdepillabout]

@f-f This PR is a rough proof-of-concept of adding a GitHub Action job for building Spago statically.

Currently, this PR just adds static job to the build.yaml GitHub Action. I'd like you to take a look at it, and if it generally looks alright, then I'd go though and add more documentation, as well as adding some code to the release.yaml GitHub Action to actually upload the static binary to the GitHub release.

One thing to notice is that building the statically-linked spago binary takes about 20m without using any sort of cache, so that seems basically in-line with the Windows an OSX builds. You mentioned in https://github.com/NixOS/nixpkgs/pull/171604#issuecomment-1118363612 about potentially having adding a cachix cache. That's something we could do to speed up the build, but I see it more as a potential future improvement, and not something that is strictly necessary to add in this PR.

[f-f]

@cdepillabout this looks amazing! ❤️

I have only one question: what would we do when upgrading Haskell dependencies? My understanding is that the static building infra from Nixpkgs is not always reliable (or at least it has not been so far, but I'd love to hear that we can trust it nowadays), so bumping the Nixpkgs commit to get the latest Haskell dependencies could be risky? But then I think that if we'd not do it we'd have to rebuild a whole lot of dependencies? (lengthening the build considerably, at least without cache)

[cdepillabout]

@f-f

I have only one question: what would we do when upgrading Haskell dependencies? My understanding is that the static building infra from Nixpkgs is not always reliable (or at least it has not been so far, but I'd love to hear that we can trust it nowadays), so bumping the Nixpkgs commit to get the latest Haskell dependencies could be risky? But then I think that if we'd not do it we'd have to rebuild a whole lot of dependencies?

In my opinion, this is basically the biggest problem.

A few months ago, there was a PR that got static-linking working pretty reliably in Nixpkgs for Haskell executables: https://github.com/NixOS/nixpkgs/pull/162374. With this PR, most Haskell executables can be built statically (at least with GHC-9). It seems like there are now enough people interesting in static-linking and cross-compilation in Nixpkgs that the Musl-related infrastructure is pretty solid.

We also have some checks in our CI to make sure that statically-linking Haskell executables is working. This gives us Musl-built GHCs for static linking from the NixOS cache, so end users (or the spago CI) don't have to build GHC themselves. In my opinion, moving forward, relying on the Haskell static-linking facility in Nixpkgs isn't a crazy idea.

However, the bigger problem is what do to when upgrading Haskell dependencies. The Haskell packages in Nixpkgs are generally set as the latest LTS release. There are times when this matches the LTS release that Spago is using, but sometimes Spago lags behind. In the past, this hasn't seemed to prove a big problem maintaining Spago in Nixpkgs, but like I said above, it would be unfortunate for non-Nix-using contributors to be faced with these kinds of errors.

My suggestion would be to move forward with this PR as-is, but keep an eye out for these types of problems in the future. If the Nix-related stuff seems to be turning away too many contributors (or taking up too much of our time fixing things), then we could always consider removing it.

[f-f]

I'll close this as we're about to switch to a PureScript-based Spago.