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

[Duncan Coutts]

On Wed, 2010-06-23 at 21:05 -0400, Gregory Crosswhite wrote:
> On 6/23/10 8:06 PM, Duncan Coutts wrote:
> > 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.
> >    
> 
> Okay, I hadn't considered this, though it seems like the real problem in 
> this situation is that someone violated the package version policy:  if 
> tar is upgraded to use a newer, incompatible version of bytestring, then 
> it should have an appropriate version bump that causes htar to ignore 
> the new version and use the older version instead.

It's nothing to do with a version policy. Letting people opt-in and then
enforcing a package versioning policy would be great, but it is
orthogonal to this problem.

Suppose both the zlib and tar packages specify "build-depends:
bytestring-0.9.*". It's entirely possible for me to install zlib, then
upgrade to a new bugfix release of bytestring, install tar (using the
new bytestring) and then build htar depending on tar+zlib. In this case
none of the developers of these packages have done anything wrong. It is
situations like this that cabal-install tries to avoid.

You could construct similar examples involving major versions rather
than bugfix versions. All you need is for someone to have tested with
two major versions and to mark their package as being able to work with
either.

I think what you mean is that cabal-install should infer from the
situation where package A needs 'C < 2' and package B needs 'C >= 2'
that it is safe for a package to depend on both A and B and to be built
indirectly depending on two versions of C. The fact that people can and
often do make packages that work with either C 1 or 2 makes this
situation less common. Also, it's not necessarily true, perhaps all it
means is that the latest version of B now needs a later C and so my
package now cannot use that later version of C because it did indeed
pass values of types defined in C between functions defined in A and B
(that is, my package has been busted by the latest release of B).

Duncan