[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Duncan Coutts]

On 23 June 2010 19:57, Gregory Crosswhite <gcross at phys.washington.edu> wrote:

> 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