On 23 June 2010 19:57, Gregory Crosswhite
cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance.
But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this.
To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality.
Actually cabal-install does not have enough information to distinguish when the diamond dependencies are definitely safe and where they might be unsafe. Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. In this situation it is essential that the tar and zlib packages share exactly the same version of the bytestring package. If they do not then we will get a type error when compiling the htar program. Now another example where using two versions of a dependency would be ok: Suppose the tar and zlib packages have QC tests in the library but they are not exported. It would be fine to have the two using different versions of the QC package, they could not interfere because no types from QC are passed between the two packages. However, as far as Cabal is concerned these two situations are indistinguishable. Cabal does not have enough information to tell them apart. It does not know that the QC deps are "private", it must assume the worst. If it did know that some deps were private then in principle we could do better. In the medium term I would like to see private dependencies added to the .cabal package description and to have that used by cabal-install (it'd also have to be enforced). In the mean time, I suggest continuing to make new major versions of packages as normal. The tools will eventually catch up. Duncan