On 2021-10-09 15:34, Ludovic Courtès wrote: > Hi Andrew, > > Preamble: Guix Home is now committed and there are bug reports coming > in. To me, that means our discussion needs to be focused on addressing > specific issues; we’re not going to redesign Guix services in this > thread. > > Andrew Tropin skribis: > > [...] > >>> Then that’s fine: you can have special code that emits those “source” >>> lines in .zshrc while still allowing users to provide their own >>> file-like object for .zshrc lines they want to add. Again, see how >>> ‘torrc’ is generated in ‘tor-service-type’. >> >> From what I understand you want a separate bashrc-file, >> bash-profile-file and bash-logout-file fields to be present, but where >> the content of those files should be inserted? At the beginning/end or >> instead of the rest of configuration? >> >> We already can achieve the same result by providing gexp, which will >> read the content of the file-like object, a very small helper for that >> (slurp-file-gexp) makes it even easier to do. Such approach is more >> flexible and doesn't seem much harder. >> >> I remember that you had concerns about slurp-file-gexp, but still don't >> understand what exactly you are concerned about. > > Let me restate my concerns: > > 1. Users are unlikely to fathom what this does, given the name. It > will end up in user configurations, yet: “slurp”? “gexp”? Sounds like a naming conecrn, I brought "slurp" word from clojure lang, but we can call it whatever sounds better for guile community generate-read-whole-file-gexp or anything else. Actually, we don't even need to have this wrapper to be present, just allow people to do #~(call-with-input-file file-like-object get-string-all) > > 2. ‘slurp-file-gexp’ returns code, as a gexp. Depending on the place > where that gexp is inserted, it may or may not work. Consider: > > (define (foo x) > #~(frob '(#$x))) > > (foo (slurp-file-gexp …)) ;d’oh! Yep, users can make mistakes, but it's not a technical problem, also, I see it quite unlikely to happen according to my experience supporting Guix Home users. > > 3. Use of ‘slurp-file-gexp’ and gexps in configuration records is not > consistent with the rest of the service APIs (and I think we can > humbly recognize that those APIs have been doing the job for a > while already.) It's not actually true, there are system services, which accept a list of strings/gexps and state it in the documentation, some of them do it in a less exlicit way, but still do, I found that trick looking at system service and made it an explicit pattern for home services. I tried to extract and follow patterns from system services, but found them quite inconsistent, so I took a few of them and wrote a few on my own. To name a few: extra-options @ alsa-configuration extra-config @ nix-configuration extra-config @ xorg-configuration extra-content @ nginx-configuration extra-config @ httpd-config-file contents @ httpd-virtualhost To make guix services configurations consistent (at least new ones) I think it would be cool to have a `Writing Service Configuration Guideline` section. I can share the design descisions I've made for home services configurations and after a discussion it can end up in a manual section giving a clean guideline, reducing subjective preferences and increasing consistency. If you are interested. > > Let’s just to the (call-with-input-file file get-string-all) dance in > places where it’s needed rather than let users call ‘slurp-file-gexp’. > This is roughly what the ‘tor-service-type’ example I gave does. > >> I'll write a few examples of service configurations and rationale behind >> the design descisions for that next week, to make the discussion more >> practically oriented. > > People are starting to use the tool and to report bugs. So, > unfortunately, we have to sort out interface issues quickly now. > > If some of the things being discussed turn out to be too complex to > address under those time constraints, we can consider taking them out > until we have a better idea on how to address them. > > How does that sound? > > Thanks, > Ludo’. -- Best regards, Andrew Tropin