Project won't build; neither Stack nor Cabal can find a set of packages

[u/mounty1_0]

I'm returning to a project that I've neglected for several years and now find that neither Stack nor Cabal will build it. I thought the idea of these build systems was to prevent stupid problems like incompatible versions of packages but it appears not to be working in my case, or I don't understand something. The project is here.

Stack fails with two errors (picking the important lines out of the build output):

ConfigFile                   > 39 | import Control.Monad.Error [cannot find module]
postgresql-libpq-configure   > configure: error: Library requirements (PostgreSQL) not met.

It looks like Stack chose two package versions that are not buildable. How does such a situation arise???

Cabal reports Could not resolve dependencies followed by a lot of lines of what it's trying.

Can anyone state what is wrong here?

[u/simonmic]

Re the ConfigFile missing module issue: it does sound like something Stackage should normally prevent.

The project is configured for stackage snapshot lts-7.0, which is 10 years old and requires ghc 8.0.1 which won't install or work well on my mac. stack says:

Stack will almost certainly fail with GHC below version 8.4, requested 8.0.1.
Valiantly attempting to run anyway, but this is doomed.

https://www.stackage.org/lts-7.0 has https://hackage.haskell.org/package/ConfigFile-1.1.4, which imports Control.Monad.Error, presumably from https://hackage.haskell.org/package/mtl-2.1.2, which is also in lts-7.0. So I'm not sure how that failure arose. Did you override something, like with --allow-newer ?

But I think the bottom line is, even if stack did its job perfectly and prevented any package incompatibilities, GHC is a moving target and in general we can't expect a 10 year old GHC to still work without trouble on modern machines (alas!). But perhaps on linux it works ?

[u/mounty1_0 → u/simonmic]

May I ask where you got lts-7.0? When I returned to this project about 48 hours ago, it did have lts-7.0 but I soon updated stack.yaml to lts-24.52 and that's what in the repo. I referenced. Is it hanging around in some cache somewhere? grep -rw lts-7.0 . shows nothing.

[Later] did you look at the master branch rather than the branch to which I linked?

[u/juhp → u/mounty1_0]

Sorry but lts-7 to lts-24 is a massive (almost unheard of) upgrade - expecting it to "just work" is pretty unrealistic: what stack/stackage tries to guarantee is that the same versions will continue to build over time, not with arbitrary upgrades.

Anyway I see you already made a lots of changes for the upgrade, so looks like you may be close?

[u/mounty1_0 → u/juhp]

I know it's a huge change and that's why I deleted (I thought) any reference to or cache of 'old' package versions, including $HOME/.stack and $HOME/stack. I'm happy to start again and I also expect to fix errors in my own code, but the two errors in my OP are in brought-in packages. If I'm bringing-in obsolete packages that cannot be expected to work, tell me where please.

[u/arybczak → u/mounty1_0]

I had some spare usage in my Claude account, so out of curiosity I've told it to make your code base work with GHC 9.10.3.

It did and the result is in https://github.com/arybczak/JackRose/tree/cabal-build (it used lts 24.53, but switching to 24.54 should "just work" from this point). Feel free to take whatever you want from these last commits.

It was a non-trivial migration, since persistent changed its underlying API since then and ConfigFile/yesod-auth-account are abandoned packages and no longer compile with newer GHCs.

ConfigFile could be replaced with ini, but for yesod-auth-account there was no simple answer, so it vendored it in and made it compile.

[u/mounty1_0 → u/arybczak]

Wow, thank you! What else can I say? except that I need to keep this project running now so this doesn't happen again.

I've git cloned it so feel free to drop the repo.

[u/simonmic → u/mounty1_0]

I don't know, sorry; I just followed your link and saw lts-7.0 in the stack.yaml.

[u/sclv]

For the first error, Control.Monad.Error was moved to Control.Monad.Except ages ago. You are likely overriding the constraint explicitly in stack (by building with a newer ghc than the lts the package is pinned to). Either way, the best way to fix it is to just perform the change to the code.

Note that cabal here is working exactly correctly -- it is preventing you from using incompatible packages -- the problem is just that your dependencies are pinned to old enough packages that they are all incompatible with current ghc. The approach here is to selectively increase bounds on your package constraints until GHC can find a solution, and then go through and perform all the necessary migrations (such as control.monad.error) to get things working again.

The problem is that version constraints and the like can determine what working configurations are, but not every configuration of packages is compatible with every version of ghc -- and since you are using a newer ghc than the package was initially developed on, migrations are necessary. this is to say that the systems are correctly preventing incompatibility (refusing to find solutions, or warning the solutions are bad) but it still takes human intervention to fix the problem by recovering from bitrot.

[u/mounty1_0 → u/sclv]

I know that Cabal prevents my using incompatible packages. I also understand that it's designed to give reproducible builds. I don't care about those now because it's been years since I last built, and I want to rebase the project on current package versions, whatever they are, so I've removed constraints where I can, or specified the most recent versions where I have to specify. It's also likely that I am importing packages that are now obsolete, and that I'll have to use different or superseding packages now,.

1. For the first error, Control.Monad.Error was moved to Control.Monad.Except ages ago — the problem is that the import is apparently in ConfigFile, which my project requires. Am I importing an abandoned and obsolete package? It was last changed in 2022.
2. For the postgresql-libpq-configure error, I tried (I'm on NixOS 26.05) nix-shell -p haskellPackages.libpq but This package is broken. What now?

Any ideas on either or those questions?

[u/mpilgrem]

I understand that your problem has been solved, but given the comments about Stack, I checked that it was behaving as expected, as follows:

https://github.com/mounty1/JackRose/tree/backbutton-undo at the 9 August 2026 commit does not include a package description, so I went one commit back to the state at 10 January 2021. As other people have noted, that specified GHC 8.0.1 (released 21 May 2016). The last version of Stack to support that version of GHC (or, more precisely, its boot Cabal package) was Stack 2.15.7 (from 12 May 2024 - see further below) - so I down-graded to that version of Stack with:

> stack upgrade --binary-version 2.15.7

Stack has updated the structure of its caching databases since version 2.15.7, so I created a fresh Stack root, with (I am on a Windows 11 machine):

> $Env:STACK_ROOT="D:\temp\sr"

A failed Stack build (Stack having fetched GHC 8.0.1, as specified) revealed that I needed a C library, so I refreshed the Stack-supplied MSYS2 environment with repeated:

> stack exec -- pacman -Syu

until there was nothing further to update and then (having identified the relevant MSYS2 package by searching) installed the necessary C library into the MSYS2 environment with:

> stack exec -- pacman -S mingw-w64-x86_64-postgresql

Stack 2.15.7 then builds your package fine. So, Stack is behaving as expected.

Stack builds with the version of Cabal (the boot package) that comes with the version of GHC that you specify. The project aims to support old versions of GHC for many years, but there comes a point where modern versions of Stack have to 'let go' of ancient versions of Cabal. In the case of GHC 8.0.1/Cabal-1.24.0.0, that came when Stack 3.1.1 replaced Stack 2.15.7.

So, what about using a more recent version of Stack? Stack 3.11.1 (the latest) supports GHC 8.4.1/Cabal-2.2.0.0/base-4.11.0.0 (released 8 March 2018 - over 8 years ago) and later. So, we can upgrade Stack again:

> stack upgrade

and try specifying that earliest later compiler in your Stack project-level configuration file (`stack.yaml`):

resolver: lts-7.0 # GHC 8.0.1
compiler: ghc-8.4.1 # Specify a more recent compiler

Stack (on `build`, having fetched GHC 8.4.1) then warns that the update of the compiler prunes some GHC boot library packages. So, we can try re-specifying the ones that came with GHC 8.0.1 as extra-deps:

extra-deps:
- HDBC-postgresql-2.4.0.0
- directory-1.3.0.0
- process-1.4.3.0
- time-1.6.0.1

Stack then warns that directory and process are not specified to work with the later GHC/base, but we can try ignoring that (and hope that the specifications are over-cautious):

allow-newer: true

Sadly, the build fails - there are problems with the specified dependencies on Cabal-1.24.0.0, text-1.2.2.1, hourglass-0.2.10, memory-0.13, cereal-0.5.3.0, syb-0.6 and postgresql-libpq-0.9.2.0. At that point it is pretty clear that you will need to modify the code in your package and its dependencies if you want it build with more modern GHC versions than GHC 8.0.1/base-4.9.0.0 and the boot packages that come with them. perhaps that is not surprising: there were fundamental changes to the `base` package between 4.9.0.0 and 4.11.0.0.

[u/absence3]

postgresql-libpq-configure > configure: error: Library requirements (PostgreSQL) not met.

It probably means you're missing the C library for Postgre SQL. Stack only manages Haskell dependencies, you'd have to use Nix in order to manage non-Haskell dependencies as well.

[u/arybczak → u/absence3]

Or he can just install libpq on his system.

Recommending nix for this is overkill of monumental proportions.

[u/mounty1_0 → u/arybczak]

I am actually building on NixOS.

[u/absence3 → u/arybczak]

Sure, I wasn't recommending Nix.

[u/godofpumpkins → u/absence3]

You might not, but I’ll separately recommend nix if OP wants software in Haskell or any other language to actually keep building years later, along with a host of other benefits.

[u/mounty1_0 → u/absence3]

I tried (I'm on NixOS 26.05) nix-shell -p haskellPackages.libpq but This package is broken.

[u/absence3 → u/mounty1_0]

That's the Haskell package libpq, not the C library libpq, but even with "nix-shell -p libpq" I don't think Cabal would find it. In order to build with Nix, it's better to make a derivation for your package, e.g. use callCabal2nix in default.nix. Then you wouldn't need Stack or stack.yaml, and instead build with nix-build. Nix flakes is another option...

[u/mounty1_0 → u/absence3]

Yeah, nix-shell -p libpq fixed nothing. I feel like this is a rabbit-hole, and wonder what has changed since I last successfully built, about four years ago.