From: muradm <mail@muradm.net>
To: "Théo Maxime Tyburn" <theo.tyburn@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Idea: Function composition to declare operating-system
Date: Tue, 30 Aug 2022 11:49:35 +0300 [thread overview]
Message-ID: <87y1v6ksmh.fsf@muradm.net> (raw)
In-Reply-To: <87edwylxe9.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5009 bytes --]
Hi,
I had similar problem popping up periodically.
So here are my 10 cents..
Théo Maxime Tyburn <theo.tyburn@gmail.com> writes:
> Hi guix!
>
[...]
>
> --BEGIN USE_CASE
> For example to add jackd to my system I need to add the
> "realtime"
> group, add some users to this group and add a
> pam-limits-service. If I
> want to remove this functionality from my system using the
> declarative
> approach I have to look down my config file for places where I
> added
> these things. Usually I partially solve this problem by putting
> comments
> to signal the purpose of each code block in the system
> declaration.
>
> But wouldn’t it be better if I just had a function `add-jackd`
> that takes an
> operating-system instance and returns the os with the extra
> functionalities ?
> --END USE_CASE
To clarify, do you ask that in the end of the day, some where
in (gnu services ...) there should be exported `add-jackd`
function? If so, I beleive that this will increase cross
dependency between things, thus decreasing flexibility.
Imagine `add-jackd` maintainer should always keep track on
what is being added into guix, that potentially may cause
conflict with jackd and/or require adjustments in `add-jackd`
function implementation.
Also, IMHO, implementation of `add-jackd` would be very
much opinionated.
>
> So that was the purpose of the experimentation. It didn’t turn
> out to be
> too complicated to implement. At least for my use case, I just
> needed to add two helper
> functions to extend users and services fields. The rest is
> handled directly by
> record inheritance and by accessing the fields of the input
> operating-system.
>
> The final declaration looks like this:
>
> ((apply compose (reverse os-functions)) minimal-os)
>
[...]
>
> (define* (extend-operating-system-services os services #:key
> (drop '()) (keep '()))
> (append (filter (lambda (service)
> (not (member (service-type-name (service-kind
> service))
> (filter (lambda (s) (not (member
> s keep)))
> (append drop
> %fixed-system-service-types)))))
> (operating-system-services os))
> services))
>
I suppose this could be useful to have it in guix toolbox,
although I would prefer to have (required '(account activate ...))
or (required %fixed-system-service-types) optional argument,
instead of refering to global constant
%fixed-system-service-types,
which might not satisfy everyone requirements.
> and also force keeping or dropping of some services if needed.
> The list
> of services that gets duplicated seems to be this one:
>
> (define %fixed-system-service-types
> '(account activate boot cleanup etc file-systems firmware
> fstab guix host-name linux-bare-metal linux-builder pam
> profile root-file-system session-environment setuid-program
> shepherd-root system user-processes))
>
> I generated the list by just checking which services get
> duplicated, so I am not
> very sure about it. There surely is a better way to get it.
>
> Anyway I can now define a function adding desktop
> functionalities:
>
> (define (x-os os)
> (operating-system
> (inherit os)
> (services
> (extend-operating-system-services
> os
> (list
> ;; slim display manager
> (service slim-service-type
> (slim-configuration
> (display ":0")
> (vt "vt7")
> (theme %default-slim-theme)
> (theme-name %default-slim-theme-name)
> (xorg-configuration
> (xorg-configuration
> (keyboard-layout
> (operating-system-keyboard-layout os)))))))
> #:drop '(gdm)))
> (packages (cons*
> ;; window managers
> i3-wm python-py3status
> emacs-nc-exwm-xdg
> (operating-system-packages os)
> ))))
>
> Of course there is room for some macros to make this more
> elegant, but
> this is the rough idea.
>
> In a way it feels like treating the operating-system like a
> service
> you can extend. Maybe it would even make sense to implement this
> as a
> service ? Not sure about that.
>
> It seems it would also be reasonable to have something like an
> operating-system-configuration record and a way to compose some
> before
> putting them into an operating-system record (it seems to be the
> approach rde `features` are based on). But I felt too lazy to
> copy all the
> fields from the operating-system record definition. There might
> be a
> way to get all the fields programatically and define a
> record/configuration though.
>
> Anyway, what do you think about this functionality? Have you
> already experimented with similar things?
> Did I reinvent the wheel? Is there a better approach?
Did you try using (modify-services ...)? Basically, you can
achieve similar goal within services list only with it.
> Anyway that was a very fun hacking session :)
>
> Happy Hacking!
>
> Théo
Thanks in advance,
muradm
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2022-08-30 9:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 15:14 Idea: Function composition to declare operating-system Théo Maxime Tyburn
2022-08-30 8:49 ` muradm [this message]
2022-08-30 10:52 ` Théo Maxime Tyburn
2022-08-31 13:08 ` Hartmut Goebel
2022-09-02 14:11 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2022-08-29 20:52 Nathan Dehnel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1v6ksmh.fsf@muradm.net \
--to=mail@muradm.net \
--cc=guix-devel@gnu.org \
--cc=theo.tyburn@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).