Package dependency graph
This is a graph showing the dependencies between the packages that come with GHC. I just added some (trivial) support to the ghc-pkg tool to generate the output in dot format, and generated the above graph with
ghc-pkg dot | tred | dot -Tsvg >pkgs.svg
Note the “tred” filter, which eliminates clutter from transitive edges. The ‘ghc-pkg dot’ command should be in GHC 6.12.1.
Looks similar to the results of Iavor’s graphmod tool: http://code.haskell.org/~dons/images/graphmod/xmonad-dot-imports.png
http://hackage.haskell.org/package/graphmod
I’ve been looking for a tool like “tred” forever. Thanks!
I’m a little surprised that base4 depends on base3. Is that intentional? It seems weird to have a package depend on an older version of itself.
@Josef: it’s the other way around, base-3 depends on base-4.
Ah, I got the directions of the arrows wrong.
But that way it seems even weirder! Was there some kind of time travel involved in writing base-3? Could you please explain this strange dependency?
base-3 is a small layer on top of base-4 that tries to present the same API as was in the original base-3, for compatibility with code that expects the base-3 API.
We could have duplicated all the code, so that neither base-3 nor base-4 would depend on the other. But then the two libraries would be completely incompatible, in that a program could not contain both. All the other libraries would have to be recompiled, essentially we’d need two completely separate sets of packages. Even if we wanted to do this, the package system can’t currently cope, because it doesn’t know how to distinguish e.g. containers-1.0 that was built against base-3.0 from containers-1.0 built against base-4.0.