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.
Yes, and that problem still isn't resolved in another since, since they share the same module names, but as of yet, still provide an incompatible API. I can't (yet) provide 'RightSemiNearRing' instances that work with both the monad transformers from transformers and mtl without deep mojo. The resolution there seems to be to bring transformers and mtl into close enough alignment that we'll be able to finally release a version of the mtl that just imports transformers and monads-fd, and provide a set of guidelines about the fact that in the switch to the next major version of mtl, the non-transformer versions of the monad-transformer stack are just type aliases. In that case the APIs are close enough that with a few breaking changes to existing users on each side, the APIs can be reconciled and the community unfractured. That said, we've had this plan waiting in the wings for months. ;)
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.
This becomes somewhat tricky. You can do this more or less with data types and classes, but with instances it is less clear how to do so. Instances (necessarily) kind of silently infect your public interface, and so this form of reasoning is at best global, not local. There has been some chatter about splitting up build dependencies into internal and external dependencies, although I don't know how serious it was, but that would be a move in this direction.
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.
Regardless, it is unlikely to be fixed before Ivan goes to release his shiny new type-family-driven FGL. =)
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.
[...]
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.
Actually, once you've given them different module names keeping the same package name _is_ an impediment. Because with different package names you could import both and provide instances for both, say, fgl's Graph, and for Ivan's very different type-family driven Graph, but you needlessly sacrifice that upgrade path for your users if you force both packages to have the same name.
Another very different consideration is that Erwig's old fgl is likely not going away any time soon. As far as I can tell nothing in the Haskell platform currently exploits type families and fgl is already in the platform. Getting the new library into the platform would take quite a while, even if it were available fully formed, debugged, and had an installed user base today.
One much weaker consideration is that out of the 23+ direct dependencies on fgl, fully half of them don't bother to specify an upper bound on the fgl version and would break immediately. That said, those packages are out of compliance with package versioning policy. =)
I agree with your point that perhaps cabal should be fixed to support explicit or implicit handling of internal dependencies. I just think that the practicalities in this situation point to fixing the problem with the tools in the room, rather than waving our hands and making it Duncan's problem. ;)
-Edward Kmett