Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

cabal-install problems on GHC 7.8 #177

Closed
lpsmith opened this Issue · 12 comments

7 participants

@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.

@lpsmith lpsmith referenced this issue from a commit in lpsmith/aeson
@lpsmith lpsmith Fix cabal-install for GHC 7.8; better support for GHC < 7.8
Proposed fix for #177.  This does have the downside that it would
immediately require text-1.1,  which might cause for some people
committed to older versions of the Haskell Platform.
2dfb890
@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 bos/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.

@bos bos referenced this issue in lpsmith/bytestring-builder
Closed

Nothing built with ghc 7.6.3 #1

@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
Owner

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.

@bos bos closed this
@bos bos reopened this
@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.

@NoMethodError

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

@cartazio
@bos
Owner

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.

@bos bos closed this
@tibbe tibbe referenced this issue in haskell/cabal
Open

Support || (or) in build-depends #2033

@bos bos referenced this issue from a commit
@lpsmith lpsmith Fix cabal-install for GHC 7.8; better support for GHC < 7.8
Proposed fix for #177.  This does have the downside that it would
immediately require text-1.1,  which might cause for some people
committed to older versions of the Haskell Platform.
e342061
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.