Hi! Pierre Neidhardt <m...@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’.
