Hi Guix, I’ve built something: http://elephly.net/graph.html This is an interactive chord diagram showing the relationship of “ghc-pandoc” to its dependencies. Each segment represents one package. Hover over a segment and all connections emanating from it will be highlighted. Zooming and panning is also supported. I’ve tried earlier to build a force-directed graph to visualise the package dependency graph, but I had to realise that a force-directed graph with the number of links and nodes that is common in software dependencies is visually indistinguishable from a cat’s hair ball. In contrast I find the chord diagram to be much clearer. I turned this into a backend for “guix graph”, so that you can generate graphs like this with guix graph --backend=d3js ghc-pandoc > graph.html There are a couple of implementation issues that I’d like to get input on before submitting a proper patch. This depends on “d3.v3.js”, which I’ve downloaded from http://d3js.org/d3.v3.js. (This is not minified and thus rather large.) In my current implementation the contents of this file are embedded in the report, because we don’t serve this file at a well-known location. Is this okay? We probably could use file:// links, but that requires knowledge about where this file is located. If it is okay to bundle d3js with Guix, where should it be installed? How can graph.scm know about the location of this file after installation? Should I add the path to d3.v3.js to “guix/config.scm.in”? The same questions apply to “graph.js”, which contains the code that’s needed to produce the chord diagram. It’s not a complete JavaScript file—it is just the “footer” that’s appended to the graph data produced by the backend in “graph.scm”. Should this go to “$out/share/guix/”? How would these files be found when using “./pre-inst-env”? Attached are patches so that you can play with this. The assumption is that “graph.js” and “d3.v3.js” are in the current directory, the same directory where you invoke “./pre-inst-env guix graph --backend=d3js …”. ~~ Ricardo