all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* A friendlier API for operating-system declarations
@ 2023-03-23  8:06 Edouard Klein
  2023-03-23 18:48 ` Josselin Poiret
                   ` (3 more replies)
  0 siblings, 4 replies; 40+ messages in thread
From: Edouard Klein @ 2023-03-23  8:06 UTC (permalink / raw)
  To: guix-devel

Dear Guixers,

For my clients and my own use, I use a layer on top of operating-system
declarations in which I create functions that take an os as a first
argument, and return an os.

With the help of the handy -> macro, I can chain them, thus allowing an
easy stacking of multiple "roles" or "functionalities" on the same
machine, and an easy transfer of said functionality to another machine:
just cut and paste one line from one declaration to the other.

I have written a tutorial for my clients here:

https://guix-hosting.com/docs/tuto/getting-started.html

that gives an example of what an os configuration may look like:
#+begin_src scheme
(->
 (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh")
 (http-static-content "sub2.example.com" #:to-dir "/srv/sub2")
 (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/")
 (add-services my-db))
#+end_src

The code of the function is on my channel:
https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm

After a few months of experience, and positive feedback from my clients,
my question to you guys is: would you be interested in mainlining this,
or should I keep my development efforts separate in my channel ?

I do think this API is easier than manipulating services, and although
extendable services are awesome and a very nifty piece of engineering,
they require quite a good knowledge of scheme and take a while to be
used to, while this new API, while way less powerful, lowers the barrier
to entry for newcomers.

They are an easy way to maintain a declarative whole operating system
configuration, with a syntax similar enough to docker and ansible that
sysadmins familiar with it can quickly get up and running, thus exposing
more people to Guix.

What do you think ?

Cheers,

Edouard.


^ permalink raw reply	[flat|nested] 40+ messages in thread
* Re: A friendlier API for operating-system declarations
@ 2023-05-19  3:31 antlers
  0 siblings, 0 replies; 40+ messages in thread
From: antlers @ 2023-05-19  3:31 UTC (permalink / raw)
  To: guix-devel, dev, edk, liliana.prikler

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

Anecdotally, my personal configurations are built out of composable
operating-system transformers that add packages, services, etc. through
trees of inherited records.

That's fairly straightforward for eg. adding packages, but becomes more
complicated when you consider modifying service configurations (which you
might want to inherit from when present and create when absent), nested
service configurations (inheriting multiple times, the whole away down), or
modifying kernel-arguments (where you might want to strip values for the
option that you're setting from existing strings).

I feel that operating-system record fields should be `extendable` in the
same way as services, and have always assumed that that's basically what
RDE's `features` are.

It would be great to have structure that eliminates some of the nesting and
boilerplate of an expression like this:
```
;; imagine if this was (imperative-ness aside) as simple as:
;; lambda os: os.services(foo).z.foo += bar

(lambda (os)
  (operating-system
    (inherit os)
    (sevices
      (modify-services
        (operating-system-services os)
        (y-service-type
          config => (y-configuration
                      (inherit config)
                      (z-configuration
                        (z-configuration
                         (inherit (y-configuration-z config)
                         (foo (cons bar
                                    (z-configuration-foo
                                      (y-configuration-z config)))))))))))))

;; And if we want to create the service when it doesn't exist?

(lambda (os)
  (operating-system
    (inherit os)
    (sevices
      (if (find (lambda (s)
                  (eq (service-kind s) y))
                (operating-system-services os))
          (modify-services
            (operating-system-services os)
            (y-service-type
              config => (y-configuration
                          (inherit config)
                          (z-configuration
                            (z-configuration
                             (inherit (y-configuration-z config)
                             (foo (cons bar
                                        (z-configuration-foo
                                          (y-configuration-z
config))))))))))
          (cons (service y-service-type
                  (y-configuration
                    (z-configuration
                      (z-configuration
                        (foo (list bar))))))
                (operating-system-services os))))))
```

[-- Attachment #2: Type: text/html, Size: 3256 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread
* Re: A friendlier API for operating-system declarations
@ 2024-02-19 22:25 antlers
       [not found] ` <87plwrj3w9.fsf@rdklein.fr>
                   ` (2 more replies)
  0 siblings, 3 replies; 40+ messages in thread
From: antlers @ 2024-02-19 22:25 UTC (permalink / raw)
  To: edk; +Cc: guix-devel

Hi!

Just wanted to say that I really admire your take on end-user service configuration in the Beaver Labs channel.

I gravitated towards composing functions over `operating-systems` myself, though my config is probably only ""notable"" for the moderately-cursed `modify-record` macro that I use to derive/configure/wrap the services[1]:

```
(define (os-with-yubi parent users*)
  (modify-record parent
    (groups -> (cons (user-group (name "plugdev")) <>))
    (users  -> (map (lambda (user)
                      (if (member (user-account-name user)
                                  users*)
                          (modify-record user
                            (supplementary-groups -> (cons "plugdev" <>)))
                          user))
                    <>))
    (services => (append <> (list
      (service pcscd-service-type)
      (simple-service 'u2f-udev-rules udev-service-type
                      (list (specification->package "libu2f-host")))
      (simple-service 'yubi-udev-rules udev-service-type
                      (list (specification->package "yubikey-personalization"))))))))
```

It's like if `modify-services` was generalized over any kind of record, but instead of using pre-defined verbs like `remove`, the `body` component of each `(field-name -> body)` clause is wrapped in an implicit SRFI-26 `cut`-like[2] form to create an anonymous function that's applied to the field's value. It's a super leaky abstraction because I use a different symbol for `->` depending on whether that record-field is a plain value, a thunk, or a `delay`-ed form (and it could be implemented more efficiently), but it greatly reduces the length and indentation level of repeatedly nested, inherited record variations.

```
((compose os-with-yubi
          [...])
   [operative-system])
```

I only wrote a handful of top-level `operating-system transformation` functions, and IIRC I only composed them at that top level; I think the way that you've broken them up into smaller forms and composed them out of each other though deeper, standard-functional composition gives you that same additive benefit over would-be nested forms, with each definition roughly matching up to one my "anonymous" invocations.

What I still dwell on is whether there's a way to further minimize the code-volume of including additional functionality (as was pondered in a prior response, and as `modify-record` does in obsoleting `modify-services`'s verbs), and how best to avoid order-dependencies and expose inherit inter-service-configuration dependencies and conflicts. Tropin's RDE uses an emacs or systemd-esque `provides`/`requires` system which is satisfying, but introduces implicit standardization on the symbols associated with software roles and builds a significant graph of them, which I feel adds to the "bulk" of the (still very elegant) solution and embraces the need to wrap every service and transformation into their cohesive system-- that's part of what's kept me on plain Guix with my bandaid-solutions (in the spirit of learning the standard approach before exploring larger systems built on top of it).

Anyway, I like your take, just fount it today and got to thinking-- thanks for putting it out there~

1: From: https://github.com/AutumnalAntlers/old-guix-config/blob/main/modules/antlers/systems/transformations/yubi.scm
2: Like `cut`, but deeper: see the `<>` symbol nested deep within in the `users` clause of the Yubi example.


^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2024-03-01 16:44 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-23  8:06 A friendlier API for operating-system declarations Edouard Klein
2023-03-23 18:48 ` Josselin Poiret
2023-03-23 20:23   ` Edouard Klein
2023-03-23 21:05 ` Liliana Marie Prikler
2023-04-13  9:42 ` Ludovic Courtès
2023-05-18 14:37   ` Edouard Klein
2023-11-24 21:43 ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Edouard Klein
2023-11-24 22:50   ` Liliana Marie Prikler
2023-11-25 20:14     ` Attila Lendvai
2023-11-26  5:36       ` Michal Atlas
2023-11-26 16:49       ` Edouard Klein
2023-11-26 18:32         ` Liliana Marie Prikler
2023-11-26 20:46           ` Edouard Klein
2023-11-27 21:09             ` Liliana Marie Prikler
2023-11-29 20:12               ` Attila Lendvai
2023-11-29 23:39                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-11-30 11:16                   ` Attila Lendvai
2023-12-01 18:18                     ` Michal Atlas
2024-02-01 13:29                     ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-01 19:43                       ` Liliana Marie Prikler
2024-02-01 20:30                         ` Attila Lendvai
2024-02-01 20:46                           ` Liliana Marie Prikler
2024-02-02 20:11                             ` Attila Lendvai
2024-02-01 21:02                           ` Ricardo Wurmus
2024-02-02 19:36                             ` Attila Lendvai
2024-02-02 20:21                               ` Vagrant Cascadian
2024-02-02 21:25                                 ` Attila Lendvai
2024-02-02  0:03                       ` Introducing Guix "Features"! Carlo Zancanaro
2024-02-18 15:07                       ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Edouard Klein
2023-12-09 10:12         ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2023-05-19  3:31 A friendlier API for operating-system declarations antlers
2024-02-19 22:25 antlers
     [not found] ` <87plwrj3w9.fsf@rdklein.fr>
2024-02-20  3:42   ` antlers
2024-02-25  9:26 ` Liliana Marie Prikler
2024-02-25 18:49   ` antlers
2024-02-25 20:47     ` antlers
2024-02-25 20:50     ` Liliana Marie Prikler
2024-02-25 21:27       ` antlers
2024-02-26 19:58         ` Liliana Marie Prikler
2024-03-01 16:44 ` Hartmut Goebel

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.