Quite related, about (guix build utils) : https://lists.gnu.org/archive/html/guix-devel/2026-05/msg00334.html
Discussion revolved mainly about pipelines, but I actually also hinted I would wish such a library out of guix. On 2026-06-10 21:29, Giacomo Leidi wrote: > Hi Guix! > > I don't know if this is a shared struggle but I sometimes feel > frustration when writing Guile programs because I'm too used to many of > the nice Guix facilities found under the (guix ...) namespace. I am of > the opinion that some of them should be in Guile itself! Speaking with > some of you at Guix Days, I discovered that it's not that simple and not > all dreams can easily become reality. In this case IIUC the main blocker > is that when bootstrapping Guix we don't use necessarily the latest and > greatest Guile version but of course we need everything that is > currently under the (guix ...) namespace. So this becomes a chicken and > egg problem. > > But! Nothing prevents us to at least extract some of the more general > purpose functionality inside standalone libraries that can be used also > in other projects. Some I really miss are: > > - (guix records) > - (guix build utils) > - (guix utils) > > and probably there are more under the (gnu build ...) and (guix build > ...) namespaces that other people may wish they could depend upon. What > is the sentiment around this topic in the community? Does anyone else > wish to use, say, (guix records) inside their own projects? > > I most certainly do, and today I have created [0] which is a plain and > simple export from fd3105ccdce6b0e646396ce81a276a756d4be755 of Guix > mainline. The library builds fine and tests work so it seems everything > is (should be? :D) set for that library to be used in any Guile project. > I noticed that Janneke's scmackerel > (https://gitlab.com/janneke/scmackerel) also uses a vendored copy of > (guix records) so I suppose that there may be people other than me that > may find such an unbundling effort useful. > > If there is no one strongly opposing this effort I would like to polish > the repository I created, move it under the Codeberg Guix organization > and prepare a patch to have Guix mainline depend on the newly created > library. Of course I have a lot of questions that maybe some of you can > answer: > > 1. I am really really bad at naming, so for now I called the library > guix-records but I don't like very much that following our guidelines > the package should be called guile-guix-records. It makes no sense to > me, but I was not able to come up with a better sounding name. Do you > have any suggestion on what naming convention we could adopt? Or should > we come up with new names (which would probably entail new Guile > namespaces) for each of the extracted libraries? For (guix records) it > could be (declarative-records) and the package name > guile-declarative-records but still, it doesn't sound very nice to me. > 2. What would be the starting version of such extracted libraries? for > now I'm using 1.5.0 as it's the closest Guix release but maybe it would > make sense to start from scratch with 1.0.0? I'm not sure. > 3. Currently I made the repository into a Guix channel. Is this > desirable? Should we setup authentication? I guess if we sign the > mainline Guix commits where we actually pin a version/commit inside the > guix package it wouldn't matter very much to sign also these > dependencies, but this is just my opinion. > 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). 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)? > > Let me know your thoughts about this, thanks a lot! > > cheers > giacomo > > > [0]: https://codeberg.org/fishinthecalculator/guix-records > -- Best regards, Nicolas Graves
