On 2021-10-08 09:56, Ludovic Courtès wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> On 2021-10-04 16:04, Ludovic Courtès wrote: >> >>> Xinglu Chen skribis: >>> >>>> On Sat, Oct 02 2021, Oleg Pykhalov wrote: >>>> >>>>> * gnu/home/services/configuration.scm (interpose): Include content of files. >>>>> (string-or-gexp?): Rename to 'file-or-string-or-gexp?' and check for file-like >>>>> object. >>>> >>>> I would call it ‘file-like-or-string-or-gexp?’, just ‘files’ doesn’t >>>> really make it clear that it should be a “file-like object”. >>> >>> As a matter of API, I would make it monomorphic: accept a file-like >>> object, period. This is what’s done for System services (and >>> polymorphic APIs are rare in general in Guix). >> >> At least some of system services are far from ideal, recently I tried to >> add rtmp section to nginx configuration using nginx system service. > > I agree that nginx config is problematic: > > https://issues.guix.gnu.org/37388 > > But IMO that’s off-topic. :-) > Even not taking into account that ngixn-configuration is not ideally implemented, probably it still relevant: 1. Highlights the problem of current service configuration implementation approach with records: we will need to mimic the whole underlying configuration language with records, for some small languages it's possible, but in general it's very thankless job, which also force use to keep an eye on upstream configuration language, possible extensions to it and keep our implementation in sync. In addition to that in most cases provided set of nested records requires destructuring and custom serialization code. Other system services also affected by this issue. 2. Usage of separate config-file fields with file-like object values is problematic: For nginx service it substitutes the whole file, for tor service it will be inserted at the end of the file for service X it will be inserted at the middle. Using a slightly different approach, implemented in many home services we get ultimate configuration flexibility, we don't need to handle existing file as some special case, create a separate field for it and wonder where it should be inserted, when provided. I'll provide more details in a separate thread, but for now just take a look at too implementations of sway services using both approaches: https://notabug.org/jbranso/guix-config/src/master/sway-service.scm#L110 https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/wm.scm#L33 >> Imagine the following use case: I want to create a home service, which >> accepts a package (zsh plugin) and adds a code for loading this package >> to zshrc, currently it's implemented like that: >> >> https://git.sr.ht/~abcdw/rde/tree/69dd2baf0384c899a4a4f97bdac8bf0b6e499b82/item/gnu/home-services/shellutils.scm#L18 >> >> Exteding the service above with `(list zsh-autosuggestions)` will add >> the following line to zshrc: >> >> source /gnu/store/w7d43gk1qszplj9i0rkzqvzz6kp88qfm-zsh-autosuggestions-0.7.0/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh > > OK. > > 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. > > I’m happy to discuss specific service examples in mode details if you > want. Overall, I’m confident Home services don’t require any pattern > that’s not already found in one of the many System services. :-) > > HTH, > Ludo’. 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. -- Best regards, Andrew Tropin