On Mon, Jul 13, 2026 at 12:04:06PM +0200, Hugo Buddelmeijer via Development of GNU Guix and the GNU System distribution. wrote: > 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 have also been thinking about this. It should be relatively feasible to parse Makefiles or Cabal package descriptions or whatever and generate many small builds that effectively are one Make rule each. With a quick look it seems Nix is also experimenting with something like that[1]. I don't even think this would be *that* much work. Certainly more than I expect to be able to do anytime soon, but if there are more people interested in working on this it might become possible. Should we add a milestone on Codeberg to plan it? Who's interested? [1]: https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic-derivations. > 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. This, however awesome, sounds much more difficult. At least I don't see a simple method for determining which part of a dependency some other code uses. With heavily modularized libraries some of this might come for free with the above file-level build jobs but with build tools or big single-file libraries it would require something more clever. - Saku
signature.asc
Description: PGP signature
