CODEWITHSUNDEEP
haskellghccompiler-warnings
robx
robx

Reputation: 2329

Severity of GHC multiple package version warning

GHC warns when a package depends on different instances of the same package via dependencies, e.g.:

Configuring tasty-hspec-1.1.5.1...
Warning:
    This package indirectly depends on multiple versions of the same package. 
This is very likely to cause a compile failure.
      package hspec-core (hspec-core-2.5.5-H06vLnMfEeIEsZFdji6h0O) requires 
clock-0.7.2-9qwmBbNbGzEOSffjlyarp
      package tasty (tasty-1.1.0.3-I8Vu9v0lHj8Jlg3jpKXavp) requires 
clock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU

Two things are unclear to me with respect to this warning:

  1. If GHC warns, and the compile doesn't fail, is everything fine? That is, could subtly conflicting instances of the same package still cause bad behaviour? (I'm imagining something like a type (Int, Int) in the public interface, with both instances of the package switching the order of the fields.)
  2. Is there a way to make GHC fail for this warning?

Upvotes: 3

Views: 69

Answers (1)

leftaroundabout
leftaroundabout

Reputation: 120711

That's not GHC what's warning you about multiple package-versions. GHC just compiles the packages that were specified... which hardly anybody ever does by hand, but let Stack or Cabal do it for them. And in this case it's Cabal giving the warning message.

If different versions cause a problem, you will in practice almost always see it at compile-time. It's most often a missing-instance error, because you're e.g. trying to use the class Foo from pkg-1.0 with the type Bar from pkg-2.0. Direct version mismatch of a data type in public interfaces can also happen.
Theoretically, I think it would also be possible to have an error like (Int,Int) meaning two different things, which the compiler would not catch. However, this kind of change is asking for trouble anyways. Whenever the order of some data fields is not completely obvious and might change in the future, a data record should be used to make sure the compiler can catch it. (This is largely orthogonal to the different-versions-of-same-package issue.)

If you want to be safe from any version-mismatch issues, you can use Stack instead of Cabal. I think this is a good part of the reason why many Haskellers prefer Stack.

Upvotes: 4

Related Questions