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
<gcr...@phys.washington.edu <mailto:gcr...@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 <d...@galois.com
<mailto:d...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
