# What's your workflow to update cabal dependencies?

**URL:** <https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475>\
**Category:** Uncategorized\
**Created:** [May 5, 2024, 12:06pm UTC](https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475 "2024-05-05T12:06:45Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lsmor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lsmor/32/3302_2.png) [@Lsmor](https://discourse.haskell.org/u/Lsmor)\
**Post date:** [May 5, 2024, 12:06pm UTC](https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475/1 "2024-05-05T12:06:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![philderbeast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/philderbeast/32/2489_2.png) [@philderbeast](https://discourse.haskell.org/u/philderbeast)\
**Post date:** [May 5, 2024, 1:00pm UTC](https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475/2 "2024-05-05T13:00:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![philderbeast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/philderbeast/32/2489_2.png) [@philderbeast](https://discourse.haskell.org/u/philderbeast)\
**Post date:** [May 6, 2024, 4:06pm UTC](https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475/3 "2024-05-06T16:06:08Z")

</div>

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](https://github.com/haskell/cabal/pull/9701) and read the [rendered docs](https://cabal--9701.org.readthedocs.build/en/9701/how-to-source-packages.html) that include this new how-to guide.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [May 6, 2024, 4:48pm UTC](https://discourse.haskell.org/t/whats-your-workflow-to-update-cabal-dependencies/9475/4 "2024-05-06T16:48:02Z")

</div>

> [@Lsmor](#):
>
> I think there should be a workflow to automatically update your `.cabal` bounds.

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

> **[GitHub - nomeata/cabal-plan-bounds: Calculate Haskell dependency ranges from multiple...](https://github.com/nomeata/cabal-plan-bounds)**
>
> Calculate Haskell dependency ranges from multiple build plans

and related bump action

> **[GitHub - nomeata/haskell-bounds-bump-action: Create PR to bump Haskell dependency bounds](https://github.com/nomeata/haskell-bounds-bump-action)**
>
> Create PR to bump Haskell dependency bounds

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](https://github.com/nomeata/haskell-candid/blob/master/ci-configs/ghc-9.10.1.config). This was very pleasant, much more than trying, noticing which library is still lagging, and trying again later.