Why Cabal changed build plans on us?

[brandonchinn178]

Copying post from https://discourse.haskell.org/t/debug-why-cabal-is-choosing-a-version/10547; cc @grayjay. --allow-newer=lrucache:containers fixes the issue, but how did this happen in the first place?

---

At commit a0b03f1b3ed7ee31b7ee19caaa58d88afa5eb9d1 in Fourmolu, in the web/site/ subdirectory, if I run cabal build --dry-run, it resolves to hakyll-3.2.0.10. If I specify --constraint='hakyll>4', it shows the version I expect, hakyll 4.16.2.2. I would expect Cabal to always choose the more recent version if it's possible, so why is it resolving to 3.2.0.10? And why did it just start doing so?

CI passed on this commit on Oct 13, 5p PST: https://github.com/fourmolu/fourmolu/actions/runs/11318705914/job/31473662650

But the same commit is getting a different build plan now. I can repro locally, but it's also happening in CI for other PRs.

[georgefst]

Well, the short answer to the question is "because the state of Hackage changed". This happens all the time.

Sometimes, there is a conflict between choosing the latest version one package and of another (in this case, hakyll and containers). In other words, if we take the set of valid build plans and partially order it such that "A > B" means "some package has a higher version in A than in B", then there are multiple local maxima. I'd hazard a guess that in the vast majority of solver invocations in the real world, there is a single global maximum, and thus behaviour is usually intuitive.

What I'd really love to see, is for cabal-install to recognise these awkward situations and somehow explain the differences between each plan to the user. Failing that, it would be great to have a section in the user's guide on the behaviour of the solver, particularly on how it decides between local maxima.

[geekosaur]

There is an upcoming change that does try to explain solver failures. Cabal doesn't keep around enough state to tell you why a solver plan changed, though; that would require an external tool to compare solver runs (possibly via comparing plan.json from different runs).

In the meantime, perhaps pinning the index state will get you back on track.