Writing a Guix service from scratch, as a beginner
9 points by aloys
9 points by aloys
Author here. I'm fairly new to Guix, so any suggestions or remarks are welcome.
Hopefully this is a helpful article to those starting their Guix journey.
FYI: the text renders off the screen and I can't scroll to view it on my phone (also visible by just narrowing the window on my desktop, in Firefox). (Also, the "About" link gives me a 404.)
I read your post carefully and it looks really good! I can definitely see all of the trial and error that went into building out this service, which is a good thing. Now that you've done the work its worth asking: why not use the built in nginx package? What about caddy made you feel like you wanted it over configuring nginx?
Thank you. This article took much longer to write than I initially intended!
I could (should?) have learnt to configure Nginx, but I have been a Caddy user for a few years and it was as good an excuse as any to get my hands dirty with a custom service.
Back then I chose Caddy for the automatic, zero-config TLS out of the box.
I commented in the other guix post but would love to hear your perspective with regards to documentation. Very few posts go into gexps and I want to know if you had any difficulty figuring things out given the available guix resources.
I think the documentation does overall a great job of introducing the concept of G-expressions. There is inherent complexity to it that cannot be avoided.
I still don't fully grasp it; my understanding of it is quite high level and fuzzy. I know just enough to get by. I expect that more pieces of the puzzle will eventually fall into the right place as I spend more time in the ecosystem.
One such area is ungexp. It is still unclear what is provided in the G-expression environment.
This is from the documentation, and it is unclear to me what is provided to the G-expression
As one would expect, the "/gnu/store/…-coreutils-8.22" string is substituted to the reference to the coreutils package in the actual build code, and coreutils is automatically made an input to the derivation. Likewise, #$output (equivalent to (ungexp output)) is replaced by a string containing the directory name of the output of the derivation.
I don't have other suggestions in how to make the documentation clearer. Documentation is tricky to write: you need enough knowledge to write it, but it's hard to remember what it's like not having this knowledge in the first place. By the time I know enough to give you valuable suggestions, I'll have forgotten what I did not understand in the first place!
Two instrumental resources in helping me build a conceptual model of them were Ludovic's paper (https://arxiv.org/abs/1709.00833) and Christopher's talk (https://www.youtube.com/watch?v=XdxYsdFOLd8).
The other unrelated gap in the documentation, in my opinion, is the activation-service-type given how common and central it is.
Not OP, but I just opted for Caddy over nginx on NixOS because Caddy has built-in support for obtaining Tailscale HTTPS certificates.