Dear Saku,
On 2026-07-14 20:07, Saku Laesvuori wrote:
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.
I had infact put an inordinate amount of work breaking up a maximialist
package ecosystem to compose Scryer-Prolog - with each tool having a
dedicated file and retaining all versions.
The outcome became redundant given the (important) work to reform Rusts
build system (shitty timing at my end, hohum).
Hopefully I can reapproach it in the future but I need to prioritise a
lot of other things now.
Kind regards,
Jonathan
