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
OpenPGP_0x4A3D07EFD05C4045.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
