Cabal has been going through some changes over the past 6 months. COVID-19 left a major impact on the status of maintenance for Cabal and cabal-install. Due to various life events, routine maintenance fell on the shoulders of a single individual, resulting in a Cabal-220.127.116.11 and cabal-install-18.104.22.168 release that took a human toll. As a result, the library and the tool were left without a primary maintainer as of its release. I mention these things, because they’re a nasty part of the OSS process, and it’s good to be aware of them, but I’d also like to highlight in particular why Cabal (resp. cabal-install) has had such a rough time over the past few years. Cabal (resp. cabal-install) is a very difficult library to maintain, and carries with it a deep burden in terms of legacy code (the breadth of GHC’s supported by the library stretches back to GHC 7.6, released in April, 2013). It also, historically, has had a very colorful history in terms of the ease of contribution processes and transparency, as well as working with other tooling. Without trying to erase anything in particular that has happened, the Cabal team would like to make some announcements and see if we can begin to establish a better dialogue with modern tooling, and help make Cabal (resp. cabal-install) a more community demand-driven project. This announcement will detail some updates to the team, as well as the direction we want to take in the future to make Cabal (resp. cabal-install) a friendlier library and tooling system to work with. We submit this to the community as an RFC, so we can take your feedback into account moving forward.
Changes in Management
The current (active) maintainer team consists of Mikolaj Konarski (Well-Typed), Francesco Gazzetta (Independent), and Emily Pillmore (Haskell Foundation).
Oleg Grenrus is no longer a maintainer of Cabal or cabal-install, and has moved into a more advisory capacity. You may see him commenting on merge requests (MRs) from time to time, helping out.
Mikhael Glushenkov and Herbert Valerio Riedel are still maintainers, but life events during the pandemic have made it hard for them to continue their work, so you may not see them for a while. We wish them well, and hope things get better soon.
Gershom Bazerman (gbaz) is an advisor of the project
One of the things that makes Cabal (resp. cabal-install) difficult to work with is the lack of component-wise exact-printing and associated data structures that allow one to manipulate .cabal and cabal.project files. We would like to change this. Workflows such as formatting, doc testing, build planning, local doc hosting, and env file manipulation are commonplace in modern Haskell. The reasons these things live in places like Oleg’s excellent cabal-extras repository, are twofold:
- Cabal does not have a round-tripping parser and pretty printer. A knock-on effect of this is that we don’t have a coherent story for talking about individual component-wise manipulation of entries into the .cabal or cabal.project files exposed at the API level. Historically, attempts at this have been made: hpack, for example, is a dependency of Stack that provides ergonomic ways of working with a .cabal file.
- Commands in the cabal-install tool are largely ad-hoc, and are difficult manipulate, accumulating cruft almost immediately due to the lack of a coherent API. For example,
cabal gen-boundsis a fantastic command, which generates reasonable bounds for a .cabal file by analyzing its dependencies. However, it’s missing half of the story: it will not update the .cabal file for you, because it has no reasonable means of manipulating dependencies in a given stanza! Additionally, consider the recent
cabal initwork, where, due to not being able to represent stanzas or package descriptions in a reasonable format, resulted in many issues over its lifetime, resulting in a near-complete rewrite over the past 6 months.
An exact printer is a byte-for-byte round tripping parser/printer combo. In order to begin clearing out the cruft, and to make working with Cabal’s constructs as friendly to tool builders as possible, we need an exact-printer, and its associated data structures. This leads me into the direction we’d like to take in the future.
Modern Haskell programmers have a few workflows that are now so common place that even GHC has started to incorporate them. Namely, doctesting, file formatting (both source and .cabal), env file manipulation, and build planning. To meet this demand, Oleg has done a great job with
cabal-extras (see above), but juggling as many binaries as there are extras is cumbersome, and there is no real reason they do not exist in the tool. In addition to incorporating extra conveniences, with the introduction of an exact-printer we can start providing a means for cleaning up the legacy cruft. As a result, we expect the timeline for the next 3.8 release to be as follows:
- Write the exact-printer and its associated data structures
- Finish the
--show-build-infointo the Cabal library as a first class feature. This will have the additional effect of improving peripheral tooling such as Haskell Language Server (HLS), and provide the ability to parallelize builds more easily.
- Incorporate a selection of Oleg’s
cabal-extraswork into the
cabal-installtool for convenience
Nice to have:
- Open season on cruft and removing the rest of the
v1legacy commands in accordance with Oleg’s plan: https://mail.haskell.org/pipermail/cabal-devel/2020-September/010488.html. A note on this that can be addressed as part of the RFC: I believe ripping off the bandaid is better than a slow and confusing sunset. Would people prefer if we just removed them by 3.8, or is there interest in keeping them alive according to schedule?
Better Contributor Onboarding
Cabal hasn’t been the most friendly place to submit a pull request due to various hurdles and attitudes. We’d like to change that. Please keep in mind that Francesco, Mikolaj and I are not the previous maintainers, and that we’re trying to start fresh here. We want your feedback, your contributions, and your ideas! After all, what is a build tool for, if not for helping users build? We’d like to make contributing to the library and tool a much more pleasant experience, and we welcome anyone and everyone to contribute. We’re working on going through the backlog and finding tickets for people to work on. Don’t hesitate to chat us up in the #hackage channel on irc.libera.chat. If you see a reference to Freenode, please alert us so that we can update it to Cofreenode and point other people to the correct network
It’s an exciting time to be a part of Cabal, and thanks for reading.
The Cabal Team