Am Freitag, dem 24.11.2023 um 22:43 +0100 schrieb Edouard Klein: > Dear Guixers, > > Here is a quick status update on my proposition to expose composable > functions to change operating-system declarations. > > Thank you all for the feedback you gave me :) It's very nice to not > be talking in the void. > > After Liliana opined that these functions should not put too much > burden on the maintainers, a position with which I wholeheartedly > agree, here is what I came up with: > > https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/functional-services.scm > > (file copied at the end of this email to make the list self-content > instead of relying on external services) > > That's a macro-writing macro called "define-os-macros-for" that, for > any service (for example nginx), defines five forms. They all > evaluate to a modified os: > > (.nginx os) ;; Add nginx in its default configuration > (.nginx os toto titi tutu... ) ;; Add nginx, with toto... given as > arguments to nginx-configuration > (+nginx os toto titi tutu...) ;; Extend an existing nginx service, > giving > toto... as arguments to simple-service > (~nginx os toto...) ;; Edit an existing nginx service, passing > toto... as > arguments to modify-service > (-nginx os) ;; Removes nginx > > You can see all of them used in: > https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm?ref_type=heads > > e.g. the mkdir-p function is a (+activation ...), > all web server functions use (+nginx...), > mumble is (.mumble... ), > os/git uses (~openssh... ). > > I've use (-foo) forms while testing, but not in production. The > others are currently running in prod on guix-hosting.com and the- > dam.org. The naming is a little confusing and imho not clearly helpful. For example, why (.nginx os) instead of the triple
(service+ OS SERVICE [CONF]) (service- OS SERVICE) (modify-service OS SERVICE UPDATE) Of course, you could also define triples (add-SERVICE OS [CONF]), (remove-SERVICE OS) and (modify-SERVICE OS UPDATE), which would fall in line with the macro approach, but keep names a little more readable. (If you want to use your names, you can rename them in #:use-modules). > -----------------functional-services.scm---------------- > (define-module (beaver functional-services) > #:use-module (gnu system) > #:export (*-append)) > > (define (syntax->string s) > "Shorthand to convert a piece of syntax to a string" > (symbol->string (syntax->datum s))) Or (compose symbol->string syntax->datum). > (define (*->string s) > "Convert into a string any symbol-like type we may encounter in a > macro" > (cond > [(string? s) s] > [(symbol? s) (symbol->string s)] > [else (syntax->string s)])) ;; assume syntax There should not be a need to define this. Try to use exact types. > (define* (*-append #:rest args) > "Return a symbol which is a concatenation of the given symbol-like > args" > (string->symbol (apply string-append (map *->string args)))) As above. > (define-syntax define-os-macros-for > ;; This macro, called like e.g. (define-os-macros-for foo) will > define four > ;; forms, .foo, +foo, ~foo and -foo > ;; > ;; These forms take an operating-system as their first argument, > and > ;; evaluate to an operating-system, which allows one to compose > them > ;; (e.g. (foo (bar os))). > (lambda (x) > (syntax-case x () > [(_ foo) > (with-syntax > ([dot-foo (datum->syntax x (*-append "." #'foo))] > [plus-foo (datum->syntax x (*-append "+" #'foo))] > [tilde-foo (datum->syntax x (*-append "~" #'foo))] > [minus-foo (datum->syntax x (*-append "-" #'foo))] > [foo-service-type (datum->syntax x (*-append #'foo "- > service-type"))] > [foo-configuration (datum->syntax x (*-append #'foo "- > configuration"))]) You're repeating datum->syntax here a bit too much for my liking. This patch is also missing the most important part of beaverlabs to make this work: the -> threading macro. Cheers