Hi Ludo, On Wed, 5 Feb 2020 at 16:18, Ludovic Courtès <l...@gnu.org> 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? It is hard to examine the graph with "guix size". Sometimes, I am doing: "guix graph foo | grep"; especially with 'bag' and friends. (I do not want to speak for Mathieu but he told me that he is doing the same time to time. :-)) I agree that using "guix size" is already enough to find the culprits. > > - 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. IMHO, there is 2 directions: add more outputs or duplicate package variants. For example Emacs: for pkg in emacs-xwidgets emacs emacs-no-x-toolkit emacs-no-x emacs-minimal; do echo $pkg guix size $pkg | tail -n1 echo "" done emacs-xwidgets total: 1222.4 MiB emacs total: 1003.7 MiB emacs-no-x-toolkit total: 522.6 MiB emacs-no-x total: 275.6 MiB emacs-minimal total: 204.2 MiB And from my opinion, not enough packages are variant-ed. > 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! I have never thought, neither tried but is it possible to find and/or build all the packages that 'inherit' from a specific one? Cheers, simon