Cabal 3.10 last call for contributions

Hi! Would you like cabal 3.10 to have your favourite bugfix, feature or overall spiffiness? If so, please let us help you help yourself. We are going to soft-freeze cabal 3.10 in a month or two and ship a little later, around the GHC 9.6 release date. There is still time to fix your favourite regression

or add your high priority feature (or argue for bumping the priority of an existing ticket)

The friendly team of cabal maintainers is at your disposal whether you need a PR review, a design discussion in a ticket, or you just get stuck or urgently need somebody to chat to (the #hackage IRC/matrix room is open).

Cabal 3.10 is going to be mostly a bugfix release, so there may or may not be a release candidate for you to try to break. However, brave people are continuously dogfooding the master branch from github artifacts (at the bottom of ‘validate’ CI jobs) or gitlab pipelines (more flavours, including statically linked Alpine Linux)

Another way you can contribute is by picking up a newcomer-labelled ticket. Yet another is triaging new tickets, e.g., via

Don’t worry if you feel you’d need to learn a lot — cabal is a large and constantly changing system, so most of us are forgetting faster than learning. However, purity, types and tests often permit to focus, code-dive and fix or improve a hot subsystem in relative isolation.

See you there,

Edited: Fixed the first link that discourse mangled.


Two examples of short (in terms of LOC) newcomer cabal tickets that are particularly tasty, important for users and not mindless at all:


BTW, if somebody could review any of the pending cabal PRs, that would help immensely:

If you only have rights to write a comment in the PR, don’t worry, ping me in the comment and either wait until I grant you full review permissions or just review informally in the comment and I will take care of the formalities with merge conditions.


And here we go! The unofficial prerelease of cabal 3.10 is out. Please install it, use it and report problems at our issue tracker at Issues · haskell/cabal · GitHub

The prerelease is called cabal and you can get it via ghcup as follows:

ghcup config add-release-channel
ghcup tui

Then enable “Show all versions” and then install and set “cabal”. Alternatively, the binaries for the same four platforms are at

Let’s do it together!


Oh, and the unofficial changelog of this unofficial prerelease is this directory:

If you stumble on a change that is not sufficiently summarized there, e.g, some backwards compat workaround hints are missing, please report that, too.

This looks like an exciting release! Unfortunately I wasn’t able to try it out since I’m using Linux on ARM64. But these change log items caught my eye:

  • #8162: New haddock-project command for easily building documentation of all local packages. And using --hackage to link to Hackage documentation for dependencies.
  • #8534: New auto-generated PackageInfo_* module that includes the package name, version number, synopsis, copyright, and homepage. I’ve often wondered why more fields from the package description aren’t included in the Paths_* module, and this adds some of them!
  • #8261: New --prefer-oldest flag for picking a build plan with the oldest versions of dependencies. This should be useful for ensuring that dependency bounds are accurate.
  • #7386: Use XDG directories, like $XDG_STATE_HOME/cabal rather than ~/.cabal/store.

Right, that’s pretty exciting stuff and there is more. :slight_smile:

Re arm64, regrettably we don’t have a permanent maintainer for our github and gitlab CI/release setups and we barely strive to keep any builds running, so Linux on arm64 just dropped off at some point. Let me see if I can get a one-time help with this particular problem…

For #8162 we need to wait for ghc release which will contain all the necessary changes that were made to haddock.

1 Like

I am very late here but I wonder if a better interface for haddock-project is to instead switch into “project” mode when there are multiple targets to generate documentation for when using cabal haddock?

Anyway to answer this question is when does one use cabal haddock and when does one use cabal haddock-project? There also seems to be a --hackage option for cabal haddock-project which is different to --haddock-for-hackage?

It seems that by default the haddock-project should place it’s output in dist folder (like all the other commands).

The haddock-project should also allow you to specify cabal targets (as well as respect whether you have configured with tests:enable, bench:enable). The documentation says it builds for “all” local components.

After all we don’t have build-project or test-project, the interface for this command seems quite strange.

1 Like

Please note that cabal/haddock support for multiple libraries/packages is a long neglected feature that we don’t attempt to suddenly get right on the first attempt, but iterate on. Users, at long last, have the ability to do anything in a (semi-)automated way with haddocks of their multi projects and we do expect plenty of feedback. Thank you also for yours, @mpickering. Did I get the story right, @coot? I wonder if we should open a ticket or designate an existing one to gether feedback on #8162 and related ones in one place. Did the last one get closed?