Solver stubbornly insists on integer-simple, but integer-gmp is available

[niteria]

I'm not 100% this is a bug, but I talked with @hvr on #GHC and he was convinced that it was.

What happens is:

Found no modified add-source deps.
Reading available packages...
/usr/bin/pkg-config --list-all
/usr/bin/pkg-config --modversion libdrm_nouveau form libdrm_amdgpu xcb-xfixes xf86dgaproto damageproto xcb-sync xcb-xselinux xcb-xtest x11-xcb xf86driproto libsepol libpcre renderproto dmxproto xcb-xvmc krb5-gssapi x11 xcb-present xcb-shape xau formw gl openssl compositeproto glproto xproto panelw icu menu xcmiscproto xcb-render xcb-dri2 panel xcb-dri3 libxslt kadm-client xcb mit-krb5-gssapi libssl xcb-xevie libexslt xext libdrm_nouveau2 xcb-composite xf86bigfontproto resourceproto xcb-dpms xmlsec1 libcrypto xpyb videoproto pthread-stubs zlib gssrpc fontutil xproxymngproto tic xdamage xcb-xinerama kdb xf86miscproto com_err libxml-2.0 xcb-res scrnsaverproto menuw ncursesw dri3proto xcb-xv fixesproto tinfo dri inputproto xcb-xf86dri xcb-damage libpcrecpp xcb-record xcb-xprint libselinux libffi xxf86vm shared-mime-info kbproto dri2proto xextproto bigreqsproto kadm-server fontsproto evieproto xfixes krb5 presentproto mit-krb5 emacs libdrm_intel xmlsec1-openssl glu xcb-glx recordproto xf86vidmodeproto xcb-shm ncurses xcb-randr libdrm_radeon xcb-screensaver xcb-xkb libdrm xineramaproto randrproto
Choosing modular solver.
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: text-1.2.1.3:+integer-simple
next goal: integer-simple (dependency of text-1.2.1.3:+integer-simple)
rejecting: integer-simple-0.1.1.1 (only already installed instances can be
used)
Dependency tree exhaustively searched.

What's expected (from what @hvr told me) is that cabal should disable the flag
automatically to try to satisfy the constraints.

Changing text-1.2.1.3/text.cabal to have:

flag integer-simple
  description: Use the simple integer library instead of GMP
  default: False
  manual: False

fixes the issue.

I've uploaded a repro script here: https://github.com/niteria/cabal-constraint-solver-repro
To run just do:

./repro

Sorry I didn't minimize it further, but it's quick to fail in the current form.

[kosmikus]

I can reproduce the first failure, but changing the flag default as described does not change anything for me ...

I may have been doing something wrong in my attempt to reproduce. Will look more closely tomorrow.

[23Skidoo]

@niteria What's the output of cabal --version?

[kosmikus]

/cc @grayjay perhaps you can take a look at this too

[ezyang]

Some other notes:

• I can't run the repro script multiple times, cabal get chokes. See cabal get is confused if the package you want to get was add-source'd to a sandbox #3795
• It's sufficient to try to get an install plan for pandoc at the very end. I haven't figured out a more minimal set of packages to add to the sandbox to trigger the solver error though. No, I get a different error in that case

[kosmikus]

Even for zip-archive alone no install plan can be found. The reason seems to be that for the setup file of zip-archive a constraint on Cabal >= 1.24 is imposed, yet the config file used for this constrains Cabal == 1.22.5.0. I cannot see that the flag integer-simple is involved in any way.

As to where the constraint on Cabal >= 1.24 comes from: it seems to be inserted in Distribution.Client.Dependency with a reference to #3199.

So my current theory is that this problem is indeed unsolvable, so there doesn't seem to be a solver bug.
The error message is admittedly misleading, because the solver just prints the first error it encounters, which sometimes has a lot to do with the real problem, but sometimes nothing at all.

Whether the Cabal >= 1.24 constraint is justified or not, I can currently not tell.

[ezyang]

@kosmikus , what can we do to improve the solver error message in this case?

[kosmikus]

@ezyang The error message problem is not specific to this case at all. Producing better solver error messages is a rather interesting problem, and it certainly would be nice if I or someone else would spend some time on this. But it's not easy.

One small thing that might help a bit that @grayjay and I wanted to do is to print the final conflict set in the case that the dependency tree gets exhaustively searched (which it is in this case). I might remember incorrectly, but I think this is already done in master?

[ezyang]

I think even the more modest goal of printing out enough information (and a sufficient -v level), so that an expert like you can debug the problem without needing a reproducible test case, would be a great improvement.

[niteria]

I see, this makes sense, thanks for investigating. When I saw the second error (about zip-archive) I assumed it was a different problem. Don't worry about the constraints on Cabal, it's a self-imposed problem, I didn't know it could cause this. I need to read #3199 to see if I'm affected.

I agree that having a better error message would help, but this is not the first constraint solver that I saw with this problem, so it might be fundamentally hard.

@23Skidoo: I'm using Cabal 1.24.0.0

[niteria]

#3199 is indeed relevant for me. zip-archive has a Custom build-type and it's the only thing imposing the Cabal 1.24.0.0 constraint. I was trying to build Cabal 1.22.5.0 among other things, so the constraints are unsolvable.

Changing zip-archive to use a Simple build-type fixed the problem for me and I was able to finally build successfully.
I must say this was very non-obvious for me and if I didn't file this issue I don't know if I'd have figured this out myself.

rejecting: zip-archive-setup.Cabal-1.22.5.0 (conflict: zip-archive =>
zip-archive-setup.Cabal>=1.24)

makes sense only after I was pointed to #3199.

Thank you for your help, from my point of view this is solved.

[ezyang]

OK, going to close.