[Haskell-cafe] Re: Rewriting a famous library and using the same
name: pros and cons
Jeremy Shaw
jeremy at n-heptane.com
Tue Jun 8 20:13:58 EDT 2010
On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> I recall having a discussion with either you or someone else from the
> happstack team about why it isn't applicable there, but the QuickCheck
> problem can be solved in the general case by having its dependency be a
> compile-time-only option which is disabled by default.
Not really. Cabal likes to recompile things, and it won't remember
that I compiled another library with quickcheck enabled. So if library
B depends on library A with quickcheck enabled, it may still happen
that after I install library A with quickcheck enabled, cabal will
decide to recompile A again when building library B, and it will
build A without quickcheck, causing B to fail...
> However, this is definitely a major problem with parsec, HaXml, etc. and
> probably what I consider the main argument _against_ keeping the same
> name for fgl, though this can occur with packages even with a relatively
> minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API
> change was minor but until all package maintainers upgraded their
> packages to work with 1.7 there would be some inconsistencies).
Right. Minor dependencies have the same issue. The only difference is
that it is generally less work for maintainers to update their code.
So maybe it happens faster/more often. But, we still run into that
issue with happstack as well. We have fixed it by sending patches
upstream. Since they are small patches it is usually easy to get them
created and applied than something like HaXml 1.13 -> 1.19.
- jeremy
More information about the Haskell-Cafe
mailing list