On 6/23/10 2:13 PM, Edward Kmett wrote:
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite <gcross@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