test Cabal in CI

[sellout]

Is your feature request related to a problem? Please describe.

We have unofficial(?) support for Cabal, but it often breaks in trivial ways because the core developers generally don’t use it and there is nothing to ensure it gets updated.

Describe the solution you'd like

A non-required GitHub check that builds with Cabal to check that it works. I don’t think a failing build should stop a PR, since we don’t need devs to spend their time figuring out how to update a build system they don’t use. But can we alert some specific volunteers who care about Cabal when it fails?

I think if we have CI, it could also be good to move cabal.project to the standard location (or at least document why it’s in contrib – which could be as simple as “This file is in contrib/ to convey that it’s not an officially supported build tool, although we do make an effort to keep it current.”)

Describe alternatives you've considered

Indicate clearly in the docs & cabal.project file exactly how unsupported Cabal is “it’s likely to be broken from time to time, but we’re open to PRs that remedy that”.

Make Cabal completely unsupported by removing the cabal.project.

I’m not a fan of either of these, especially since Cabal is the de facto tool for so much in the Haskell ecosystem.

[aryairani]

This all makes sense.

I'd still simply call it unsupported for now; if it's anything but unsupported, I would want it to always build.

For this reason, we resisted including a cabal.project for a long time, but eventually caved to requests to include it in contrib/ (there, to convey that it's not an officially supported build tool, even if it's the defacto tool and even used by stack, if I understand correctly).

[sellout]

As @aryairani mentioned in https://github.com/unisonweb/unison/pull/5142#issuecomment-2229027412, there are some concerns with a Cabal CI check.

To mitigate the concern re: GitHub resources, @aryairani suggests only running on Linux, not running tests, and using a build cache. I wonder if it can be even more reduced – running just the solver could get us pretty far. The individual .cabal files are already tested as part of the Stack build. And maybe somehow checking that manually pulled packages have matching SHAs between stack.yaml and cabal.project? (But the overhead here may well outweigh the GH resource concerns, and risk causing more work to keep such ad-hoc comparisons working).

Also, there is a problem I fight with in both stack.yaml and cabal.project – they don’t affect actual .cabal files. This is useful when setting a flag like -Werror that is intended only for local development, but can be problematic in other cases (especially when publishing libraries to Hackage, which I don’t think we do at all).

Moving more settings into package.yaml from stack.yaml means fewer things that can get out of sync between Stack and Cabal. The tradeoff is those settings are now duplicated in every package.yaml, but the generated .cabal files would stand alone (at least more so). I have used/do use hpack-dhall to make it possible to share common settings between hpack files, but that also seems like an unnecessary level of indirection (again, especially since we’re not publishing to Hackage).

[sellout]

I'd still simply call it unsupported for now; if it's anything but unsupported, I would want it to always build.

Some projects specify platform support tiers: https://zcash.github.io/zcash/user/platform-support.html. With what we’re discussing here (non-required build), it seems like Cabal would be tier 3 according to that particular definition. If we made the build required, but not run the tests, it’d be tier 2. I think Stack is currently tier 1 and Nix is tier 2. Correspondingly, Ubuntu, x86 Macs, and Windows … 11(?) are tier 1 and M1 Macs are … tier 3?

Not that any of those are official, just inferred from what we currently build/test.

For this reason, we resisted including a cabal.project for a long time, but eventually caved to requests to include it in contrib/ (there, to convey that it's not an officially supported build tool, even if it's the defacto tool and even used by stack, if I understand correctly).

Yeah – no one wants to re-implement parsing Cabal files 😅

Then I think keeping it in contrib is good, we can just add some comment/docs about its support level (or lack thereof).