On 6/23/10 2:13 PM, Edward Kmett wrote:
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
<gcr...@phys.washington.edu <mailto:gcr...@phys.washington.edu>> wrote:
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.
This works fine as long as no detail of the embedded library leaks
into the public API. QuickCheck is typically the least painful library
to mix, since you don't typically use the quickcheck properties from
multiple quickcheck versions drawn from other packages at runtime.
Yes, but if details of the package you are using are "leaking" out into
the interface then you will have the same kind of problems whenever that
package conflicts with any other package, regardless of whether the
conflict is with a package of the same name. For example, for a while
there was a conflict between mtl and transformers because they shared a
package name, and the fact that the two packages had different names
didn't make the problem any better.
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.
cabal is the only mechanism that the vast majority of Haskell-users
know how to use these days. Resolving diamond dependencies safely
relies on knowing tha tthe use of different libraries is entirely
internal to the library in question -- a detail that is not currently
exposed through the cabal file. You can use PackageImports to try and
hack around common package names at least in GHC, but it then further
confuses purpose and provenance.
But cabal can see with exactly which packages each of the dependencies
requires, right? So what is stopping it from just walking through the
dependencies and constructing the dependency graph? It should have all
of the information it needs to do this.
To the extent that the full information that cabal needs exists and yet
it is not capable of recognizing this, I would view this as a bug in
cabal that we should fix, rather than deciding just to live with this
bug and limiting ourselves to a subset of the package dependency
functionality.
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.
There are multiple potential implementation semantics that can be
assigned to a diamond dependency. The types could be incompatible.
They could be compatible, and the most recent version should be used
by all (in case of minor API changes). They could be somewhere in between.
Yes, but again this will happen whenever you use two packages that
conflict, regardless of whether they just happen to have the same name
or not, as it did for a while with mtl and transformers. Renaming fgl
to newfgl won't actually make this situation any better.
I suppose where we differ is in how big of a concern we view 'just
cabal having a problem with it' is. All I can say is that every time
there has been a major API change where half the community hasn't
moved, it has been a practical problem. It become yet another
implementation detail that every subsequent developer has needed to
consider, and providing support and instances for both is impractical.
My point isn't that it is not a big deal that cabal has a problem with
it, it is that this is something that we should fix *in cabal* since
there is nothing intrinsically intractable about it. Furthermore, the
kinds of problems that people encounter in such transitions won't be
fixed merely by changing the name of the package since conflicts can
still appear with the old package.
If we really are worried so much about these kinds of conflicts, then
the real solution is to make sure that none of the modules exported by
the new package share the same name as the modules in the old package.
And if one is going to do that anyway, then from the perspective of
resolving conflicts there isn't any additional benefit to also renaming
the package.
Cheers,
Greg
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
