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

22 Jun 2010

      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 
mailto:gcross@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 mailto:dons@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@haskell.org mailto:Haskell-Cafe@haskell.org
    http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
    Haskell-Cafe mailing list
    Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org
    http://www.haskell.org/mailman/listinfo/haskell-cafe