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

[Gregory Crosswhite]

There is no reason that your program couldn't link to multiple versions 
of the same package so that each library can access the version that it 
needs.  In fact, GHC already does this, doesn't it?  For example, I use 
a mixture of libraries in my programs that link to QuickCheck 1 and 
QuickCheck 2, and this works just fine.

The only problem I've had is with cabal, which when resolving 
dependencies seems to only be able to pick out one version of a 
package;  in some cases instead of running "cabal install A B" where A 
and B depended on different versions of the same package (QuickCheck) I 
had to instead separately run "cabal install A" and "cabal install B".  
This isn't a big deal, but I could imagine cases where it could fail to 
automatically install a package entirely due to conflicting version 
requirements.  This, however, is not because there is an intrinsic 
problem with installing multiple versions of a library, but simply 
because cabal sometimes seems to get confused about what it needs to do.

So in short, I see no problem with there being multiple versions of a 
package floating around, and to the extent that an implementation of 
something can't handle this it seems like this is arguably a bug in that 
implementation rather than a bug in the package system for allowing the 
possibility.

Cheers,
Greg

On 6/22/10 4:06 PM, Edward Kmett wrote:
> The problem is that nothing breaks immediately.
>
> Then someone else comes along and transitively depends on your package 
> and on another package, which depends on the newer version.
>
> Your users wind up with strange conflicts like that if they are using 
> Parsec 3 they can't use HTTP.
>
> Or if they use fc-labels they can't use any library that internally 
> uses mtl, because fc-labels uses transformers. Or worse they want to 
> use a library that used fc-labels internally with another library that 
> used mtl internally.
>
> It fragments the library base that you are able to use.
>
> Version caps are not the answer.
>
> -Edward Kmett
>
>
> On Tue, Jun 8, 2010 at 2:21 PM, Gregory Crosswhite 
> <gcross at phys.washington.edu <mailto:gcross at phys.washington.edu>> wrote:
>
>     Or you just put an upper bound on the versions of the fgl library
>     that your program will build against, as you should be doing
>     anyway, and then nothing breaks.
>
>     Cheers,
>     Greg
>
>     On Jun 8, 2010, at 11:08 AM, Gene A wrote:
>
>>
>>
>>     On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart <dons at galois.com
>>     <mailto:dons at galois.com>> wrote:
>>
>>
>>         (... There have been a few cases of major API  / rewrites to
>>         famous old
>>         packages causing problems, including:
>>
>>            * QuickCheck 1 vs 2
>>            * parsec 2 vs 3
>>            * OpenGL
>>         ...)
>>
>>         (...  * No additional breakages are introduced. ...)
>>
>>
>>     Oh lord yes...  just call it fgl3  and leave the fgl package alone.
>>     This is a source based community here... so you take a package that
>>     has a dependency on another library and you go out and get that
>>     to cover the
>>     dependency and the API is not the same!!!  AND especially if that
>>     might be the
>>     only thing you will ever use that lib for ... and you have to
>>     stop and rewrite the
>>     original.. and as someone else said with maybe documentation of
>>     that API that
>>     is not maybe finished or...  NO ... At that point the person will
>>     probably just
>>     DISCARD the compile on the lib or program that had the
>>     dependency.. rather
>>     then put the effort in to learn an entire API that doesn't match
>>     up..
>>     BAD IDEA!!
>>
>>     cheers,
>>     gene
>>
>>     _______________________________________________
>>     Haskell-Cafe mailing list
>>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100622/c6317179/attachment.html