Split `Cabal` into `Cabal-syntax` and `Cabal`?

[gbaz]

As discussed in #7548 (comment) , some people find a dependency on the full Cabal library somewhat heavyweight for just doing cabal file parsing without actually executing any builds.

In general, I think splitting off the basic file parsing and syntax tree stuff of the lib into Cabal-syntax or the like would be a fine idea, and probably help with code organization to boot.

Maybe this could be a next step after the exactprint work, and it might also help encourage ides to integrate with the cabal library.

A bit more wild of an idea maybe the functionality of https://hackage.haskell.org/package/cabal-install-parsers could be deprecated by moving cabal-install's parsers into Cabal-parsers as well.

Ideally I think this (along with exact-print) would help tools be more comfortable using the already built utilities for cabal files instead of rolling their own (or punting).

[gbaz]

Note that hvr also has an experimental cabal-parsers library (unreleased on hackage) that glues together the parsing code from various cabal versions so it can run them explicitly to check: https://github.com/haskell-hvr/cabal-parsers/ -- Pulling out Cabal's parser stuff into its own lib could considerably simplify such a package (but more generally pinning down a properly versioned cabal bnf etc could obviate the need for it).

[phadej]

I'm 👎 on moving cabal-install-parsers stuff into Cabal-syntax. The cabal-install files (cabal.config, cabal.project) are cabal-install specific, e.g. stack will do completely nothing with them. Also these files change more often. Cabal-syntax library is big on its own, no need to artificially enlarge its API surface.

cabal-parsers idea is to be bug compatible. It's a pragmatic way to check that old cabal-installs can parse stuff uploaded on Hackage, removing the burden of being bug-compatible from the Cabal(-syntax) library itself.

[phadej]

I'm pretty sure that Cabal-syntax dealing only with .cabal files could be even pulled out of this repository and developed and maintained by different (can be obviously overlapping) folks in their own pace. That's another argument to not couple it to cabal-install.

The only change needed for new GHC releases in format part of the lib, IIRC, is adding extensions & languages. Woiuld be nice to refactor the library to make those changes non-breaking changes PVP-wise. (I doubt anyone does exhaustive pattern match on extensions, yet there is only three languages, so someone might do that). TL;DR Language and Extension type could be made opaque or internal, so adding new constructors won't force major version bump.

[gbaz]

Ok, I'm fine with cabal-install-parsers not getting moved as well -- I did say it was a more wild idea :-)

The proposal on Language and Extension being opaque makes a lot of sense as well.

[patrickdoc]

I took a crack at this to get familiar with the code base. In #7620 I've mostly just done the mechanical part of the separation, without any refactoring/renaming of anything. Cabal spit pretty naturally into two pieces, with [Generic]PackageDescription on one side and the Distribution.Simple stuff on the other.

If you think this is along the right lines, I'm open to refactor as much as you'd like. Otherwise I'm also fine to just scrap it :)

[phadej]

@patrickdoc That is great! I'll take a look.

[Mikolaj]

#7620 has been merged. What next?

[Ericson2314]

git grep -w IO Cabal-syntax/ is a pretty quick-and-dirty way to find bits and pieces that should probably be moved back to Cabal.

[Mikolaj]

@Ericson2314: you mean, re-exported from Cabal?

[Ericson2314]

I mean moved back out of Cabal-syntax. I think a good heuristic is anything that mainly exists to provide some data types shouldn't be doing much IO, so looking through the IO usage is a good way to double check the work.

As far as I can tell the initial split was done not super fine-grained ---- which makes sense! Keeps the diff less unruly. We also did fairly simple splits when breaking up https://github.com/simonmar/happy for the same reason. But once the initial split is done, then a second pass can polish things up. I think going through the IO is a good way to do that second pass.