[Haskell-cafe] Do something about Cabal?

[jack at jackkelly.name]

December 11, 2020 7:50 PM, "Bardur Arantsson" <spam at scientician.net> wrote:

> On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
>
>> [snip]
>
> Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
> Cabal or Stack. They do different things well/badly. Until we get a tool
> that can do everything the schism will probably remain.
> 
> (And that's not even talking about issues like technical debt in each of
> the code bases, etc.)

I'm glad my message was taken in the right way.

> My problem here is that Cabal hasn't provided some very useful the
> features that YAML does out of the box, namely the ability to define
> arbitrary snippets of package configuration and to refer to them from
> multiple places. Examples:
> 
> If I maintain a cohesive set of 5 packages, I need to duplicate various
> bits and bobs of information in 5 different places:
> 
> [snip things that really should be DRY'd up by a modern build tool]

While it does not solve the problem you have in full, common stanzas can at least help you de-duplicate ghc-options settings within a package. https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas

A possible solution: allow cabal.project to set common entries across multiple packages, and have `cabal sdist` write them into the cabal file that goes into the tarball? This is just me spitballing, so there are probably problems that I haven't considered.

> This is tedious at best and outright wrong
> at worst (inconsistent version bounds).
> In no way am I advocating for YAML specifically.
> (Dhall could work here since you can at least do inclusions and reuse in
> a generic way. Plus it has fully defined semantics plus implementations
> in at least a couple of langauges, Haskell and Scala.)

I see that Oliver has already mentioned dhall-to-cabal . I'm a fan, but I'd be worried about bootstrappability if it became the main language of the main build tool.

>> - Many stack projects do not provide bounds on dependencies
> I posit that at least a *part* of the problem here is tedium for
> maintainers (see above), but while we're at it: I'm not sure manually
> maintaining bounds is at all scalable nor particularly "correct" (for
> lower bounds, esp.) unless one is *super*-vigilant about what bits of a
> dependency are *actually* in use.
> 
> FWIW, I do try to do this for my packages, but I'm very confident that
> all of my packages probably have misleading lower bounds.
> 
> It seems to me that some automated tooling is needed here, e.g. to try
> building/testing with e.g. all deps at the lower bound, all deps at the
> highest bound, etc.

No doubt. The only way to have a hope of doing this is with a CI matrix. https://github.com/haskell-CI/haskell-ci used to get some of the way there, but Travis CI recently yanked the rug out from under FOSS projects. I believe there is active work to make that repo support other CI systems. (More hands would probably help.)

A possible compromise for bounds: use ^>= bounds, raising the lower bound when you either a) need something from a new version, or b) move to a new major version? If you remain open to metadata revisions that relax the lower bound if needed, that might be OK? Again, spitballing, and I expect some kind soul to point out the flaws in this plan.

Best,

-- Jack