Ludovic Courtès <l...@gnu.org> writes: > Ricardo Wurmus <rek...@elephly.net> skribis: > >> I’ve built something: >> >> http://elephly.net/graph.html > > Awesome! Much better than staring at a static graph in Evince. > >> 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. > > Are there other types of visualizations supported by d3 that would help?
Yes. A force-directed graph could be made clearer by applying force bundling as is done here: <https://github.com/upphiminn/d3.ForceBundle>. We could map the graph to a collapsible tree such as this <http://codepen.io/mikefab/full/IDdts/>. One disadvantage of using a tree is that we can no longer visually unify shared inputs. We could also provide a variant of the chord diagram by bundling edges as is done here: <http://mbostock.github.io/d3/talk/20111116/bundle.html>. We’d lose the relative “importance” of a package, which in a chord diagram can be seen in the radial size of a segment, but dependencies might be clearer. (Graphviz-style representations are more difficult, because the location of the nodes needs to be laid out first, whereas in d3 no pre-computation takes place.) So, lots of things that a dedicated hacker could implement :) >> I turned this into a backend for “guix graph”, so that you can generate >> 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. > > What about having a fixed-output derivation (aka. ‘origin’) to download > that file from a stable, versioned URL? > >> 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”? > > An option is to download it to the store on demand. The downside, of > course, is that it would require network access. > > If the .js files were to be installed, I agree with using PREFIX/lib/js > as Pjotr suggests. Does this mean that the generated HTML document would have to be a gexp referencing the file in the store? (I’m not sure how to implement this, but with a pointer or two I could give it a try anyway.) >> Should this go to “$out/share/guix/”? How would these files be found >> when using “./pre-inst-env”? > > Well, if it’s just the small graph.js, you could store it in moduledir, > like we do for patches. This is a hack, but the advantage is that we > can just use (search-path %load-path …) to find them, regardless of > whether we’re using ./pre-inst-env or not. Okay. > Otherwise we could add a new GUIX_JAVASCRIPT_PATH env. var. and > corresponding ‘search-javascript-file’ procedure. I like this a little less than the “search-path” option. ~~ Ricardo
