Re: Guix size reduction work group

[zimoun]

Hi Pierre,

On Sat, 8 Feb 2020 at 17:43, Pierre Neidhardt <address@hidden> wrote:

> >> - Improve the tooling.  In my experience, guix graph is quickly unusable
> >>   with a high number of nodes.  Maybe d3.js could be leveraged to add a
> >>   filtering system, or a way to click on nodes to hide them and all
> >>   their children.
> >
> > ‘guix size’ is key here: it’s a profiler, exactly what we need IMO.
> > WDYT?
>
> Maybe I'm missing something, but in general I think that guix size only
> gives a birds eye view and does not allow for closer inspection.
>
> Say FOO has BAR in its closure, but not in the explicit inputs, how can
> I figure out which of the indirect inputs drags BAR in?

I do not understand what you are looking for, but there is already:

   guix graph -t reverse-package
    guix graph -t reverse-bag

that does more or less what I understand you want.


> With an extensive guix graph, it quickly becomes impossible to follow
> the millions of arrows.

Using a static graphviz, I agree. And I generally end up by grepping
directly in the 'dot' output file.

Maybe something more dynamic using 'd3.js' or similar to view *big*
graphs could help.



> What I'd like to have is an interactive graph that I can trim to links
> between given nodes.  This would allow me to ask "give me the dependency
> chain that links FOO and BAR".

I agree that tools to work with the graph would be welcome.
Currently, the graph is here but under-used, IMHO.

The first step seems to list what operations and filtering is missing.



> > The thing is, I think it’s something that requires constant care, every
> > time we add a package or modify an existing one.  It’s very easy to lose
> > benefits that had been previously obtained through hard work!
>
> This is a good point.  "Adding" a package is less critical since it does
> not impact the closure size of the rest.  For "updates" maybe we could
> leverage the continuous integration to flag a warning when a new build
> has increased the size of the package compared to a previous build by
> some threshold.

You could propose such feature to the Guix Data Service.
For example, on this webpage [1], the history of all the Git package
in Guix is shown. The closure size could be reported.

[1] http://data.guix.gnu.org/repository/1/branch/master/package/git



All the best,
simon