26.05.2024 22:51:33 CEST Richard Sent: > Hi Marek! > > > I have already built the infrastructure to host my configurations on my > > home server. I would like now to ditch the configuration repositories' > > clones in the home directories on my computers and rely entirely on the > > combination of the system-wide channels (this I have implemented) and the > > /etc/config.scm file. > > > > Is there a way to have 'guix pull' edit the /etc/config.scm file to mirror > > the designated system configuration file? I assume that any module > > imports are handled by an existing guix infrastructure, because I had no > > need to use the -L switch during reconfigurations for a while. > > If your channel includes the configuration files for the target > machines and you are successfully adding those channels to the system, > you could take advantage of Guix's -e flag. e.g. > > --8<---------------cut here---------------start------------->8--- > $ guix system reconfigure -e '(@ (my-custom-channel machines this-machine) > use-this-system)' > --8<---------------cut here---------------end--------------->8---
Yes! This is exactly what I hoped for! Thank you very much. For anyone reading this in the future: the code is '(@ module-name procedure-name)'. The operating-system record needs to be named with a define-public. > When combined with unattended-upgrade-service-type [1] and embeddeding a > "self-referential" channels.scm file in your configuration [2] (a > channels.scm file that contains it's own repository), your systems would > regularly reconfigure themselves using the newest versions of your > channel machine configuration files. Sounds lovely, but I would need to construct a continuous integration subsystem to be to able to use it. I tend to experiment a lot while programming and I do not trust myself to just upgrade automatically to the newest revision of my code. Most of my reconfigures fail, due to any number of reasons. Now I really need to come up with a nice channel / distribution name. The number of modules in my codebase is about to explode and I can already tell that renaming them after the fact would be… painful and tedious. > [1]: > https://git.sr.ht/~freakingpenguin/rsent/tree/ 1b79ec8a91a9546d4cc158590b1d50145e5fe42a/item/rsent/machines/droplets/ rampart.scm#L69 > [2]: > https://git.sr.ht/~freakingpenguin/rsent/tree/ 1b79ec8a91a9546d4cc158590b1d50145e5fe42a/item/rsent/configs/channel.scm#L13
signature.asc
Description: This is a digitally signed message part.
