cabal-install problems on GHC 7.8

[lpsmith]

Aeson 0.7 doesn't cabal-install properly on GHC 7.8. Here I'm trying to install aeson with a package database populated only with default libraries:

lpsmith@church:~
$ which ghc
/usr/local/hs/ghc-7.7.20140110/bin/ghc
lpsmith@church:~
$ cabal install aeson
Resolving dependencies...
Configuring bytestring-0.10.2.0...
Building bytestring-0.10.2.0...
Preprocessing library bytestring-0.10.2.0...
^C

The problem is that the dependency solver is doing too much work keeping the new-bytestring-builder flag set to False, and installing an older copy of bytestring (which tends to cause a whole host of other problems). This is solvable by manually setting the flags appropriately, but still creates difficulty for many users.

One possible solution would be to add a dependency on the bytestring-builder package, which compiles on GHC-6.12 and onwards, providing the new bytestring builder in a convenient package for older GHCs without upgrading bytestring itself. (bytestring-builder will compile as an empty package when compiled against newer versions of bytestring, if you've upgraded bytestring on an older ghc.) Then you could get rid of the new-bytestring-builder and blaze-builder flags altogether.

You may want to hide this dependency behind an if impl(ghc < 7.8) conditional, to avoid the need of including the bytestring-builder compatibility package along with the Haskell Platform. This assumes that anybody using GHC-7.8 or later would also be using bytestring-0.10.4 or later, which should be a safe assumption.

[hvr]

I just got here, after I had to install aeson (or actually some package that depended on that) via

cabal install --constraint 'bytestring installed' aeson

to keep it from downgrading bytestring...

(PS: see also haskell/text#67)

[dcoutts]

Right, the aeson package specifies:

flag new-bytestring-builder
  description: Use the new bytestring builder available in bytestring >= 0.10.4.0
  default: False

...

  if flag(new-bytestring-builder)
    other-modules: Data.Aeson.Encode.ByteString
    build-depends: bytestring >= 0.10.4.0,
                   text >= 1.1.0.0
  else
    build-depends: bytestring < 0.10.4.0,
                   text >= 0.11.1.0

so indeed, the solver is going to try if at all possible to respect that flag default and try to use bytestring < 0.10.4.0 and text >= 0.11.1.0. If that turns out to be impossible then it'll try new-bytestring-builder = True.

The problem here is that we are using flags for a purpose that they were not really designed for, but we don't currently have a better way to express. The heurisitcs for flags work fine for things that we really think of as flags (like "try to add tls support if possible, don't bail out just because they don't have the tls package installed currently"), but the heuristics on how hard you should try don't work well for things like "if we're using bytestring >= 10.4 then we also need text >= 1.1".

I have thought about adding a new construct like:

  build-depends: foo
  if package(foo >= 3)
    ...

which would act like:

flag internal_1

  build-depends: foo
  if flag (internal_1)
    build-depends: foo >= 3
  else
    build-depends: foo < 3

But the heuristic in the solver would be different. It wouldn't try as hard to make the flag go one way or the other.

As things stand however, that's the behaviour and so the best thing to do in the short term is to change the aeson package.

[kosmikus]

I've pushed an experimental change to the solver to my cabal-install fork: kosmikus/cabal@814e493

I think it might fix the original issue mentioned here. However, I haven't done proper testing yet. It might well not solve other similar issues, or cause regressions for other dependency resolution problems.

[bos]

For those tuning in from home, this is a little blocked on a fix from @lpsmith that unfortunately doesn't yet work with modern Cabal.

[cartazio]

@kosmikus is this fork on top of the current 1.19 branch? If so i'll try it (been wanting to try out that use newest flag)

[kosmikus]

@cartazio It's on top of the master branch, if that's what you mean. But I'd expect the patch to be easy to cherry-pick into another branch as well.

[cartazio]

i'll have a look see later this week. buried with other stuff :(

[lpsmith]

Well, in all fairness, it depends on your definition of "modern" cabal. bytestring-builder works fine with the current release, but not the development version.

[knardi]

Just dropping a note that this is still affecting people on the release version of GHC 7.8.1.

[cartazio]

Everyone on 7.8.1 is advised to upgrade to 7.8.2. There was a nasty bug in
the former.

On Monday, April 14, 2014, NoMethodError [email protected] wrote:

Just dropping a note that this is still affecting people on the release
version of GHC 7.8.1.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/177#issuecomment-40426199
.

[bos]

This continues to be a problem with GHC 7.8 and cabal-install 1.20, and I'm afraid I still have not much of an idea how to resolve it.

One possibility that I'm considering is writing a custom Setup.hs that will try to do the right thing.

[hvr]

Yesterday, @tibbe uploaded new versions of cabal-install for the 1.18 and 1.20 branch which should hopefully resolve this issue.