On 13/7/26 11:17, Cayetano Santos wrote:
Sure, as a user of trealla, having an immediate access to every single line change is great, but Guix is ~ 30k packages, and so my question, is that on purpose and really needed by anyone ? What would happen if this way of proceeding spreads ? To think about.
Taking a really long term perspective, it would be nice if we could build packages 'in parts'.
E.g. the difference in trealla v2.94.16 and v2.94.15 is one commit with one line changed in one file. Then it would be nice if the build of trealla v2.94.16 could take the build of trealla v2.94.15 and rebuild just that one file.
Such a system would require something like splitting up the packages into individual steps. Maybe making the dependency graph a graph of individual files, with the current package-based graph a 'view' on this per-file graph. Some build systems would make this easier than others.
I actually thought about this in the context of forks. It becomes easier and easier to create your own version of software you use. 'Software as a home cooked meal.' But if everyone will have their own version of every piece of software, then we'd need something to make that scale.
Such a sub-package build won't be simple, but the Guix fundamentals put us in a great position to think along those lines.
It would be even nicer if we could build packages partially. That is, some packages are huge, with a large set of optional components. But if the ultimate packages at the top level manifest only use a small subset of that functionality, then only that small subset needs to be build for that particular manifest.
How awesome would that be? You make a one line change, deep down in the dependency graph, and you rebuild your world in minutes instead of weeks, without grafts. And that work is reusable if you need an other, but overlapping, set of features later.
Guix is a huge step in making such futures attainable.
