On 6/23/10 3:29 PM, Edward Kmett wrote:
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. ;)
Oh, cool, so that's the plan? Grr, if I had fewer projects I would
volunteer to help out with this. :-)
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.
But does cabal even need to do an analysis that is that sophisticated?
All it needs to see are the package dependencies in order to note that,
"Oh, this package requires version X, and this package requires version
Y, so therefore I need to install both!" rather than saying, "Hold on,
these two packages require *different versions* of the same package? I
give up!"
And conflicts between instances and things need to be taken care of
before the package can even be built, let alone uploaded to Hackage. So
while I agree that these are problems, they are not really cabal's
problem to worry about since by the time cabal has been brought into the
picture they must have already been resolved.
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. =)
Fair point. :-)
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.
Okay, so the assumption is that although dependencies could use
different versions of a package with the same name, when you yourself
use a package you can only use one particular version of the package.
Given this assumption I see your point, though perhaps it would be a
good idea to allow package imports to also allow you to specify the
major version number of the package you can import modules from two
different major versions of a package.
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.
Good point, but on the flip side, if the new versions of fgl is much
better than the old version and is eventually taken into the Haskell
Platform, then does this mean that the old version will be deprecated
and eventually removed, or will they both be kept around for the long term?
For comparison, as I understand it seems that Python has generally had
the strategy of keeping around old packages for a long time for the
purpose of backwards compatibility. When a new and much better version
comes along they would give it a new name and mark the old package as
being deprecated --- at least for a while; after a long period of
deprecation they would eventually remove the old package.
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. ;)
Fair enough. :-) I am willing to agree that this makes sense as a good
short-term pragmatic solution, regardless of whether it is the ideal
long-term solution.
Cheers,
Greg
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe