Re: d3js chord diagrams

[ludo@gnu.org (Ludovic Courtès)]

Hi!

Ricardo Wurmus <rekado@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?

> 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.

> 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.

Otherwise we could add a new GUIX_JAVASCRIPT_PATH env. var. and
corresponding ‘search-javascript-file’ procedure.

> 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 …”.

Just tried it and it works like a charm.  :-)

Thank you!

Ludo’.