<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Greg<br>
<br>
On 6/22/10 4:06 PM, Edward Kmett wrote:
<blockquote
cite="mid:AANLkTinx46WwqXPeITUsJavx5S2ZoEGBYpOlNiQBetxg@mail.gmail.com"
type="cite">The problem is that nothing breaks immediately.<br>
<br>
Then someone else comes along and transitively depends on your package
and on another package, which depends on the newer version. <br>
<br>
Your users wind up with strange conflicts like that if they are using
Parsec 3 they can't use HTTP.<br>
<br>
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.<br>
<br>
It fragments the library base that you are able to use. <br>
<br>
Version caps are not the answer.<br>
<br>
-Edward Kmett<br>
<br>
<br>
<div class="gmail_quote">On Tue, Jun 8, 2010 at 2:21 PM, Gregory
Crosswhite <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gcross@phys.washington.edu">gcross@phys.washington.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;">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.
<div><br>
</div>
<div>Cheers,</div>
<div>Greg<br>
<div><br>
<div>
<div>
<div class="h5">
<div>On Jun 8, 2010, at 11:08 AM, Gene A wrote:</div>
<br>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5"><br>
<br>
<div class="gmail_quote">On Tue, Jun 8, 2010 at 8:08 AM, Don
Stewart <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dons@galois.com" target="_blank">dons@galois.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(... There have been a few cases of major API / rewrites to famous old<br>
packages causing problems, including:<br>
<br>
* QuickCheck 1 vs 2<br>
* parsec 2 vs 3<br>
* OpenGL<br>
...) <br>
</blockquote>
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(...
* No additional breakages are introduced. ...)<br>
</blockquote>
<div><br>
Oh lord yes... just call it fgl3 and leave the fgl package alone.<br>
This is a source based community here... so you take a package that<br>
has a dependency on another library and you go out and get that to
cover the<br>
dependency and the API is not the same!!! AND especially if that might
be the <br>
only thing you will ever use that lib for ... and you have to stop and
rewrite the<br>
original.. and as someone else said with maybe documentation of that
API that<br>
is not maybe finished or... NO ... At that point the person will
probably just <br>
DISCARD the compile on the lib or program that had the dependency..
rather <br>
then put the effort in to learn an entire API that doesn't match up.. <br>
BAD IDEA!!<br>
<br>
cheers,<br>
gene <br>
</div>
</div>
<br>
</div>
</div>
<div class="im">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a moz-do-not-send="true" href="mailto:Haskell-Cafe@haskell.org"
target="_blank">Haskell-Cafe@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://www.haskell.org/mailman/listinfo/haskell-cafe"
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a moz-do-not-send="true" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://www.haskell.org/mailman/listinfo/haskell-cafe"
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>