Howdy! You’re tackling a longstanding need!
Giacomo Leidi <[email protected]> skribis: > - (guix records) > - (guix build utils) The problem with these two is that they’re really closely tied to Guix. (guix records) does not evolve much but it’s nice to have it serve Guix’s need and to be able to use its features right away in Guix. A recent example is a7c8e68dc51144a6d3981b770aca9c4897fc7c0c and its child commit 2a50c9598bb7fe4175c4f29df07656a7f0a07801. This kind of thing becomes much harder when depending on an external library because in that case you usually want to have loose coupling with said library (that is, Guix would probably not require the latest release of guix-records, and thus we’d have to wait to use the new feature), and the library itself may have more stringent compatibility requirements (it may be doing semver, avoid incompatible changes, etc.) I guess I’m just describing the advantages of a monorepo. :-) Maybe the solution for now is to keep Guix as the source of these and to periodically copy to these external libraries with minor modifications like changing the module name? (Sorta like how Gnulib does with glibc code.) That may sound boring but it would still be an improvement over the status quo. > 4. I noticed that the current test-driver.scm from Guix mainline > (which I copied in the guix-records tree) uses features available only > in Guile 3.0.11 (notably test-match-all). According to ‘configure.ac’ Guix requires 3.0.9+ so this (using 3.0.11-only features) is a bug. > Should we make sure that these extracted libraries build correctly > only with the latest Guile version or should we strive for them to be > compatible also with older versions (including 2.2 and 2.0)? That’s another tricky part. For (guix records), we can require 3.0.9+ because that’s what Guix requires. But (guix build utils) itself has to work with 2.0 (!) because that’s what ‘guile-bootstrap’ is on x86, and it’s also used for some of the tests. If it were extracted, it would make sense to drop 2.0 (and even 2.2), but then it would become a problem for Guix. HTH! Ludo’.
