On 6/23/10 2:13 PM, Edward Kmett wrote:
> On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
> <gcross at phys.washington.edu <mailto:gcross at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100623/6afb7064/attachment.html