cabal check doesn't account for conditionals

[bgamari]

In binary-serialise-cbor we are trying to provide exposed-modules for GHC 7.8, where reexported-modules is not supported. For instance,

library
  default-language:  Haskell2010
  hs-source-dirs:      src
  if impl(ghc >= 7.9)
    reexported-modules:
      Codec.Serialise            as Data.Binary.Serialise.CBOR,
      Codec.Serialise.Class      as Data.Binary.Serialise.CBOR.Class,
      Codec.Serialise.Decoding   as Data.Binary.Serialise.CBOR.Decoding,
      Codec.Serialise.Encoding   as Data.Binary.Serialise.CBOR.Encoding,
      Codec.CBOR.FlatTerm        as Data.Binary.Serialise.CBOR.FlatTerm,
      Codec.Serialise.IO         as Data.Binary.Serialise.CBOR.IO,
      Codec.CBOR.Magic           as Data.Binary.Serialise.CBOR.Magic,
      Codec.CBOR.Pretty          as Data.Binary.Serialise.CBOR.Pretty,
      Codec.Serialise.Properties as Data.Binary.Serialise.CBOR.Properties,
      Codec.CBOR.Write           as Data.Binary.Serialise.CBOR.Write,
      Codec.CBOR.Term            as Data.Binary.Serialise.CBOR.Term,
      Codec.Serialise.Tutorial   as Data.Binary.Serialise.CBOR.Tutorial
    exposed-modules: Data.Binary.Serialise.CBOR.Read
  else
    -- GHC 7.8 doesn't support module re-exports
    exposed-modules:
      Data.Binary.Serialise.CBOR,
      Data.Binary.Serialise.CBOR.Class,
      Data.Binary.Serialise.CBOR.Decoding,
      Data.Binary.Serialise.CBOR.Encoding,
      Data.Binary.Serialise.CBOR.FlatTerm,
      Data.Binary.Serialise.CBOR.IO,
      Data.Binary.Serialise.CBOR.Magic,
      Data.Binary.Serialise.CBOR.Pretty,
      Data.Binary.Serialise.CBOR.Properties,
      Data.Binary.Serialise.CBOR.Read,
      Data.Binary.Serialise.CBOR.Write,
      Data.Binary.Serialise.CBOR.Term

  build-depends:
    base < 5,
    bytestring < 1.0,
    cborg     == 0.1.*,
    serialise == 0.1.*

Unfortunately, cabal check fails on this with,

$ cabal check
The package will not build sanely due to these errors:
* Duplicate modules in library: Data.Binary.Serialise.CBOR,
Data.Binary.Serialise.CBOR.Class, Data.Binary.Serialise.CBOR.Decoding,
Data.Binary.Serialise.CBOR.Encoding, Data.Binary.Serialise.CBOR.FlatTerm,
Data.Binary.Serialise.CBOR.IO, Data.Binary.Serialise.CBOR.Magic,
Data.Binary.Serialise.CBOR.Pretty, Data.Binary.Serialise.CBOR.Properties,
Data.Binary.Serialise.CBOR.Read, Data.Binary.Serialise.CBOR.Term,
Data.Binary.Serialise.CBOR.Write

Hackage would reject this package.

It seems that Cabal doesn't account for the conditional when computing this check.

[hvr]

@bgamari a quick workaround (until this is fixed in lib:Cabal & deployed on hackage) is that you can make two releases which differ only by patch-level, and let the solver pick the right one for the respective compiler (there's at least another package who does this on Hackage, but for other reasons).

So i.e. release

• binary-serialise-cbor-0.1.0.0 w/o reexported-modules and with if impl(ghc >= 7.9); build-depends: base<0 (i.e. causing the solver to avoid this release with ghc >= 7.9)
• binary-serialise-cbor-0.1.0.1 with reexported-modules and with if !impl(ghc >= 7.9); build-depends: base<0 (i.e. causing the solver to require ghc >= 7.9)

This has also the benefit that cabal-version: for the 0.1.0.0 release can be lower, as it doesn't contain reexported-modules.

[fendor]

There is this comment in the code: https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/Check.hs#L62

Does somebody know how to patch that in Hackage, or is there a reason for it to be like that?

I assume, this is a non-trivial issue, as you either should make cabal check make aware of all conditional paths, or only report problems for the currently generated PackageDescription, which depends on the local compiler, etc...

[hsyl20]

Hackage check seems to be done here: https://github.com/haskell/hackage-server/blob/8cebbe6c6341537b1c75281482cc1ca9a5c4153a/Distribution/Server/Packages/Unpack.hs#L290

• In both cases (Hackage and cabal-install), we shouldn't pass a flattened pkg desc to checkPackage, passing Nothing would have the same effect.
• checkPackage (

  cabal/Cabal/src/Distribution/PackageDescription/Check.hs

  Line 145 in 0b06a13

  checkPackage :: GenericPackageDescription

  ) should be fixed so that checkLibrary isn't called with a flattened pkg desc.

[jneira]

I am afraid that haskell-language-server hackage release is blocked on this (via ghc-api-compat).
@hsyl20 many thanks for investigating it, it seems both hackage-server and cabal-install should be fixed (although the firs one will suffice to upload the package i guess)

[fendor]

@jneira fyi, I am working on a patch that drops the ghc-api-compat dependency.