Have to install twice package with 'custom-setup' stanza

[garetxe]

I just uploaded a new version of the gi-glib package to hackage using the new custom-setup stanza, but cabal install fails to install it on the first try:

$ cabal sandbox init
Writing a default package environment file to
/home/inaki/tst/cabal.sandbox.config
Creating a new sandbox at /home/inaki/tst/.cabal-sandbox

$ cabal install gi-glib-0.0.2.2
[... work for a while ...]
Installed Cabal-1.24.0.0
[... work some more ...]
Configuring gi-glib-0.0.2.2...
Failed to install gi-glib-0.0.2.2
Build log ( /home/inaki/tst/.cabal-sandbox/logs/gi-glib-0.0.2.2.log ):
cabal: Entering directory '/tmp/cabal-tmp-23716/gi-glib-0.0.2.2'
cabal: Leaving directory '/tmp/cabal-tmp-23716/gi-glib-0.0.2.2'
cabal: Error: some packages failed to install:
gi-glib-0.0.2.2 failed during the configure step. The exception was:
user error (The package 'gi-glib' requires Cabal library version -any &&
>=1.24 but no suitable version is installed.)

Notice that Cabal-1.24.0.0 was installed properly, but somehow the configure of gi-glib still fails. But repeating the command now suceeds:

$ cabal install gi-glib-0.0.2.2
Resolving dependencies...
Notice: installing into a sandbox located at /home/inaki/tst/.cabal-sandbox
Configuring gi-glib-0.0.2.2...
Building gi-glib-0.0.2.2...
Installed gi-glib-0.0.2.2

[garetxe]

For reference, here is the .cabal file for the package (from https://hackage.haskell.org/package/gi-glib-0.0.2.2/gi-glib.cabal):

name:               gi-glib
version:            0.0.2.2
x-revision: 1
synopsis:           GLib bindings
description:        Bindings for GLib, autogenerated by haskell-gi.
homepage:           https://github.com/haskell-gi/haskell-gi
license:            LGPL-2.1
license-file:       LICENSE
author:             Will Thompson, Iñaki García Etxebarria and Jonas Platte
maintainer:         Iñaki García Etxebarria (garetxe@gmail.com)
category:           Bindings
build-type:         Custom
cabal-version:      >= 1.24

extra-source-files: GLib.overrides

custom-setup
  setup-depends: base >= 4.7,
                 Cabal,
                 haskell-gi >= 0.15

library
    default-language:   Haskell2010
    default-extensions: NoImplicitPrelude, ScopedTypeVariables, CPP, OverloadedStrings, NegativeLiterals, ConstraintKinds, TypeFamilies, MultiParamTypeClasses, KindSignatures, FlexibleInstances, UndecidableInstances, DataKinds, FlexibleContexts
    other-extensions:   PatternSynonyms ViewPatterns
    ghc-options:        -fno-warn-unused-imports -fno-warn-warnings-deprecations

    pkgconfig-depends:  glib-2.0
    build-depends: base >= 4.7 && <5,
        haskell-gi-base >= 0.15 && < 1,
        bytestring >= 0.10,
        containers >= 0.5,
        text >= 1.0,
        transformers >= 0.5

[sebright]

It seems to be related to having cabal-version: >= 1.24 in the .cabal file. I wrote a simplified test case that installs a package with setup-depends: Cabal > 1.24 to force cabal to install a newer version of the library when using GHC 7.10. cabal installs Cabal-1.24.0.0 and then fails while configuring the package with the custom setup. If I instead use cabal-version: >= 1.2, the build succeeds.

sebright@6607bb7
https://travis-ci.org/grayjay/cabal/jobs/136044168#L3956

I also noticed that the dependency solver doesn't enforce the cabal-version constraint, even though it is enforced during configure.

[sebright]

I found the problem. cabal always chooses a Cabal library version to use for a package's setup script that doesn't take setup-depends into account. It is assigned to cabalLibVersion on this line:

cabal/cabal-install/Distribution/Client/SetupWrapper.hs

Line 355 in dc3eca7

(cabalLibVersion, mCabalLibInstalledPkgId, options') <- cabalLibVersionToUse

. cabalLibVersion depends on the cabal-version field, the installed versions of Cabal, etc., and it is used when setup dependencies are not chosen by the dependency solver. When a package has a setup-depends, cabalLibVersion is later ignored in favor of the version chosen by the dependency solver. The configure step in my test case fails because cabal uses a stale snapshot of the installed package index when choosing cabalLibVersion, and it doesn't see that Cabal-1.24.0.0 has been installed.

I think the solution is to only choose cabalLibVersion when cabal is not using a version of Cabal chosen by the dependency solver. It would also fix the misleading log message

cabal/cabal-install/Distribution/Client/SetupWrapper.hs

Line 356 in dc3eca7

debug verbosity $ "Using Cabal library version " ++ display cabalLibVersion

.

Here is a commit that seems to work: sebright@9f6cbea?w=1. It probably isn't complete, though.

[ezyang]

@grayjay are you still planning to fix this?

[sebright]

@ezyang I'm not sure if my commit is the right approach. This issue could require a bigger change, but I'm not very familiar with the code that chooses the Cabal version.