Fail to build with cabal-install

[ulysses4ever]

General summary/comments (optional)

Stack 2.3.1 fails to install for me when using Hackage and cabal-install.

Steps to reproduce

1. cabal update
2. cabal install stack

Expected

Stack installs.

Actual

...
Building library for stack-2.3.1..
...
[ 29 of 109] Compiling Stack.Types.Resolver ( src/Stack/Types/Resolver.hs, dist/build/Stack/Types/Resolver.o, dist/build/Stack/Types/Resolver.dyn_o )

src/Stack/Types/Resolver.hs:71:17: error:
    Ambiguous occurrence ‘SnapName’
    It could refer to
       either ‘Stack.Prelude.SnapName’,
              imported from ‘Stack.Prelude’ at src/Stack/Types/Resolver.hs:34:1-30
              (and originally defined in ‘pantry-0.5.0.0:Pantry.Types’)
           or ‘Stack.Types.Resolver.SnapName’,
              defined at src/Stack/Types/Resolver.hs:67:1
   |
71 | instance NFData SnapName
   |                 ^^^^^^^^

There are several more errors of the same kind (Ambiguous occurrence) after this first one -- about LTS, Nightly, etc.

Stack version

2.3.1.

Method of installation

• Via cabal-install
• GHC version: 8.10.1
• Cabal version: 3.2

[kirelagin]

That is because SnapName was copied to pantry-0.5.0.0 and, apparently, now it gets re-exported from Stack.Prelude. You need pantry < 0.5 to build this version of stack.

[ulysses4ever]

Thanks, @kirelagin, it does work with the constraint, indeed. I'm not sure if the issue should be closed or not, so I leave it to decide for those more knowledgeable.

[jwaldmann]

Sometimes this helps: if there is a successful build report on hackage (in this case, https://hackage.haskell.org/package/stack-2.3.1/reports/1), do

cabal update 'hackage.haskell.org,2020-04-29T20:25:58Z'

(use the date of the report) then cabal install.

[jwaldmann]

currently, this seems to work for stack-2.3.3 and -2.5.0.1, with ghc-8.10.2 and -8.8.4:

cabal install --constraint 'base16-bytestring==0.1.1.7' --constraint 'optparse-applicative==0.15.1.0'

(that's the versions given in the stackage resolver)

[arrowd]

I was able to compile Stack with simple cabal new-update && cabal new-configure && cabal new-build.

[jwaldmann]

Yes. Can confirm. Then it should also work on hackage? https://hackage.haskell.org/package/stack-2.5.1/reports/ has "no reports available".

[jwaldmann]

Truly, a never-ending story. Today's (Tue Nov 10 21:05:29 CET 2020) magic spell seems to be

cabal install  --constraint 'persistent==2.10.*'  stack-2.5.1

[jwaldmann]

while today it's cabal install stack --constraint 'persistent-template==2.9.1.0' for me.

[EDIT] or something along those lines. Anyway the algorithm is: copy exact versions for the failing packages from the official resolver, e.g., https://www.stackage.org/lts-17.9/package/stack-2.5.1.1/deps.

[jwaldmann]

seems to work for stack-2.7.1 as well:

cabal install stack  --constraint 'persistent-template==2.9.1.0'

with hackage of today (index-state 2021-05-08T10:46:01Z)

[jwaldmann]

I was trying to cabal-install stack-2.7.5. It seems that this works (cf. JustusAdam/mustache#58)

cabal v2-update 'hackage.haskell.org,2022-03-10T11:40:42Z'
cabal install -w/opt/ghc/ghc-8.10.7/bin/ghc stack-2.7.5 --constraint 'unordered-containers<0.2.17' --constraint 'aeson<2'

This pinning of cabal's index is like a poor man's resolver - except that it isn't, since cabal still prefers installed versions? Anyway I checked that the above works after rm -rfv .cabal/store/ghc-8.10.7/ (which also destroyed my cabal executable ...)

[Bodigrim]

@jwaldmann I don't follow: stack-2.7.5 mandates aeson < 1.6 and mustache >= 2.3.1, which implies unordered-containers < 0.2.17. So both --constraint in your incantation are redundant and I believe that fixing index-state is redundant as well. At least, stack install stack-2.7.5 succeeds on my machine as is.

[hasufell]

@jwaldmann I don't follow: stack-2.7.5 mandates aeson < 1.6 and mustache >= 2.3.1

I guess some people might experience the result of #5677

It's not clear from the reports if people cloned the repo and attempted install or pulled from hackage.

[jwaldmann]

Sorry, it's a mess. This works (indeed, not extra constraints)

cabal install  -w /opt/ghc/ghc-8.10.7/bin/ghc --index-state='2022-03-10T11:40:42Z' --one-shot stack-2.7.5

but I'm not at all sure about those cabal options (whether they make the build reproducible). Anyway I thought it's good to note a buildable hackage state, for when I might need to re-build this in a few weeks, or months, time.

[hasufell]

(whether they make the build reproducible)

That depends on what you mean by that. Pinning index state doesn't ensure the same resolution, mainly because of package flags and pkg-config depends. So you'd want to freeze the resolution as well. Then the "only" thing left for reproducible builds are fixing GHC (because it's non-deterministic) and the rest of your environment (system libs, ...).

[Bodigrim]

As a Hackage trustee, I made a bunch of revisions, prohibiting unbuildable configurations. This is far from bulletproof, but at least shields from most common conflicts.

https://hackage.haskell.org/package/pantry-0.2.0.0/revisions
https://hackage.haskell.org/package/pantry-0.4.0.2/revisions
https://hackage.haskell.org/package/pantry-0.5.2/revisions
https://hackage.haskell.org/package/pantry-0.5.2.1/revisions
https://hackage.haskell.org/package/pantry-0.5.2.2/revisions
https://hackage.haskell.org/package/pantry-0.5.2.3/revisions

https://hackage.haskell.org/package/stack-2.1.3.1/revisions
https://hackage.haskell.org/package/stack-2.3.1/revisions
https://hackage.haskell.org/package/stack-2.3.3/revisions
https://hackage.haskell.org/package/stack-2.5.1/revisions
https://hackage.haskell.org/package/stack-2.5.1.1/revisions
https://hackage.haskell.org/package/stack-2.7.1/revisions
https://hackage.haskell.org/package/stack-2.7.3/revisions
https://hackage.haskell.org/package/stack-2.7.5/revisions

[ulysses4ever]

Whoever reports on sucessful builds, please, specify versions of GHC and cabal you're using. I currently fail to build stack-2.7.5 (sources delivered by cabal get stack-2.7.5) using GHC 9.0 and cabal 3.6 because it wants an older Cabal, which, in turn, requires an older base:

❯ cabal build -j                                                                                                                                                                                                                                                    0 (0.007s) < 18:09:34
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: stack-2.7.5 (user goal)
[__1] trying: base-4.15.1.0/installed-4.15.1.0 (dependency of stack)
[__2] next goal: Cabal (dependency of stack)
[__2] rejecting: Cabal-3.4.1.0/installed-3.4.1.0 (conflict: stack =>
Cabal>=3.2.1.0 && <3.4)
[__2] skipping: Cabal-3.6.3.0, Cabal-3.6.2.0, Cabal-3.6.1.0, Cabal-3.6.0.0,
Cabal-3.4.1.0, Cabal-3.4.0.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '>=3.2.1.0 && <3.4' from
'stack')
[__2] rejecting: Cabal-3.2.1.0 (conflict: base==4.15.1.0/installed-4.15.1.0,
Cabal => base>=4.6 && <4.15)
[__2] skipping: Cabal-3.2.0.0, Cabal-3.0.2.0, Cabal-3.0.1.0, Cabal-3.0.0.0,
Cabal-2.4.1.0 (has the same characteristics that caused the previous version
to fail: excludes 'base' version 4.15.1.0)
[__2] rejecting: Cabal-2.4.0.1 (conflict: stack => Cabal>=3.2.1.0 && <3.4)
[__2] skipping: Cabal-2.4.0.0, Cabal-2.2.0.1, Cabal-2.2.0.0, Cabal-2.0.1.1,
Cabal-2.0.1.0, Cabal-2.0.0.2, Cabal-1.24.2.0, Cabal-1.24.0.0, Cabal-1.22.8.0,
Cabal-1.22.7.0, Cabal-1.22.6.0, Cabal-1.22.5.0, Cabal-1.22.4.0,
Cabal-1.22.3.0, Cabal-1.22.2.0, Cabal-1.22.1.1, Cabal-1.22.1.0,
Cabal-1.22.0.0, Cabal-1.20.0.4, Cabal-1.20.0.3, Cabal-1.20.0.2,
Cabal-1.20.0.1, Cabal-1.20.0.0, Cabal-1.18.1.7, Cabal-1.18.1.6,
Cabal-1.18.1.5, Cabal-1.18.1.4, Cabal-1.18.1.3, Cabal-1.18.1.2,
Cabal-1.18.1.1, Cabal-1.18.1, Cabal-1.18.0, Cabal-1.16.0.3, Cabal-1.16.0.2,
Cabal-1.16.0.1, Cabal-1.16.0, Cabal-1.14.0, Cabal-1.12.0, Cabal-1.10.2.0,
Cabal-1.10.1.0, Cabal-1.10.0.0, Cabal-1.8.0.6, Cabal-1.8.0.4, Cabal-1.8.0.2,
Cabal-1.6.0.3, Cabal-1.6.0.2, Cabal-1.6.0.1, Cabal-1.4.0.2, Cabal-1.4.0.1,
Cabal-1.4.0.0, Cabal-1.2.4.0, Cabal-1.2.3.0, Cabal-1.2.2.0, Cabal-1.2.1,
Cabal-1.1.6, Cabal-1.24.1.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '>=3.2.1.0 && <3.4' from
'stack')
[__2] fail (backjumping, conflict set: Cabal, base, stack)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: stack, Cabal, base

Allow-newer Cabal allows the solver to succeed but the build fails because of API changes in the newer Cabal.

[Bodigrim]

No stack release is buildable with GHC 9.0 at the moment.

[ulysses4ever]

This is helpful, thanks. I wish the cabal file was more specific in the base >=4.10 && <5 bit.