What's your workflow to update cabal dependencies?

#1

Context: I have updated my ghc to version 9.8.2. As usual, some dependencies aren’t working anymore… Also as usual, a simple cabal build all --allow-newer resolve the problem. Now, everytime I run a command I have to pass the --allow-newer flag, which is anoying.

I think there should be a workflow to automatically update your .cabal bounds. I’ve tried cabal gen-bounds but it turns out it tries to build the project and find a conflict… surprinsingly gen-bounds command doesn’t accept --allow-newer flag, nor freeze files nor project files.

I find there is a tool called cabal-bounds but I can’t be built with ghc-9.8.X as far as I can tell.

So the question is: do you deal with upper (or lower) bounds manually or automatically, which workflow fits you better

1 Like
#2

Here’s a sketch of a workflow I use;

  1. Start with a wide allow-newer: * bounds exception to relax upper bounds to see if I can get a compile.
  2. Remove the allow-newer: * and narrow the exception scope to allow-newer: dep-x:* or allow-newer: dep-x:dep-y.
  3. Fork dependencies that need work, taking source-repository-package dependencies on them in a cabal.project, fixing their problems and making pull requests to the upstream repository.
  4. Move the source-repository-package dependency to point to the upstream repository when the pull request is merged.
  5. Remove the source-repository-package dependency when or if a new version of the dependency is published to Hackage.

I prefer to work with a cabal.project when adding allow-newer exceptions. I don’t think it is possible to redirect a dependency with source-repository-package from the command line.

7 Likes
#3

I’ve written a “How to shepherd package source code” guide for Cabal’s docs that includes discussion of source-code-repository. There’s still time to add your comment and review to haskell/cabal#9701 and read the rendered docs that include this new how-to guide.

2 Likes
#4

My approach now is to never write cabal bounds manually anymore, but instead set up a CI matrix for all the configurations I like to test, and then derive the bounds from that, i.e. don’t include any versions that I am not testing.

The tool for that is

and related bump action

They are not perfect and may not fit every use-case, but maybe you’ll like them.

For the 9.10 bump I was able to do it with one of my libraries even before all dependencies have been updated on hackage, using allow-newer and source-repo, see haskell-candid/ci-configs/ghc-9.10.1.config at master · nomeata/haskell-candid · GitHub. This was very pleasant, much more than trying, noticing which library is still lagging, and trying again later.

6 Likes