Re: Guix size reduction work group

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Shall we start a work group to fix the issue?
>
> - Write a blog article to explain the issue and a detailed process on
>   how to fix it.  (Embed it to the manual.)

The “Submitting Patches” section mentions closure size specifically.  Is
there anything you think we should add there?

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

> - How do we compare to Nix?

A few years back we were doing better because we used separate outputs
in key places where Nixpkgs didn’t.  Later on Nixpkgs had a large part
of its packages split in several outputs (more than we do).  From what I
heard, it wasn’t as fruitful as they had hoped it would be in terms of
closure size, but it might still be better than what we have, dunno.

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!

At any rate, I agree we need to improve!

Ludo’.