From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id IFjqM4L0DWMfJgEAbAwnHQ (envelope-from ) for ; Tue, 30 Aug 2022 13:29:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id KFLPM4L0DWPkvAAAauVa8A (envelope-from ) for ; Tue, 30 Aug 2022 13:29:06 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6C61016D3B for ; Tue, 30 Aug 2022 13:29:06 +0200 (CEST) Received: from localhost ([::1]:36386 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSzQX-0007sC-IZ for larch@yhetil.org; Tue, 30 Aug 2022 07:29:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSzQM-0007ro-IJ for guix-devel@gnu.org; Tue, 30 Aug 2022 07:28:54 -0400 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:43686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oSzQK-0006we-CK for guix-devel@gnu.org; Tue, 30 Aug 2022 07:28:54 -0400 Received: by mail-ed1-x536.google.com with SMTP id c59so7555174edf.10 for ; Tue, 30 Aug 2022 04:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:from:to:cc:subject:date; bh=XABJokzLHN9UcDKsHDDmZ4raTONwEeR6ikFwe/hJpFY=; b=GBaUrJxlrwiCDM4GvJFG13X1G3UOtonFSI51DxxrtUyJfbCbWZR4rVn1kpQp3rlVRG ypAfwrgfQRPjrBcBXRADYvtscTvO9vBjl/fErMehlw+qRCvYDZFb/q1h5pFORiXgCTSy BeMz6YdhZg/M40GswxFdGpPkD6l0mBrkxW4fdyQyPV4vK+Pe1NOoDskJbJLJVBAGO8A3 CQMrnKeWVqf10Y5xlY+e5oKvjw+puGA6Mz+XNSaaSe9mMuyUSzNu79GA8QR4DT5PKNze 4fbu6+Ff7ilQO5nVAqmN/P9QeQWOrJ+Bi58T0f7IX6/paz3nUTAotJAR3tJBxUGAQY8P H19A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date; bh=XABJokzLHN9UcDKsHDDmZ4raTONwEeR6ikFwe/hJpFY=; b=lDTMEXzk1F8/6kvGGMpq00i+wla0n5taZC1HDV8d/5od4AgOr7mZV+C7neGFJH3Kn8 AJkOS2/N8vglVVix80d2EIq3JE7Kuxj8I9X+Xl8P+IO6DlEzmfsEJEJId67bK0HGsQSE ter6TfYJDU9Kck/gHXTYFXI3b5XhzLJaYiI5GcltG38PrYBGBZY3R8jGa518tNuIL6FO kBnaLu3v9eT5EnQ+M0YeYdKNhZ40useKsoy29SiIvohLH3XHbiFSLeddpTWg6z9+A5Pg 3uQwJXzc7pThJYRO5199CfFFAHlYNuRcMASxB8ritooRWkqUF4F/qGHoMSgg+oGnzoMC yKuw== X-Gm-Message-State: ACgBeo2zEgHsPNFy/3lkgTWkdJ30f8+5i0wB3e7YoguZqy1KETy4ErRb hPHq2QzI9Uu+K9NmjlNbGG3/0i/tTdM= X-Google-Smtp-Source: AA6agR7eI6fekDWXEFahvCw8fXgA1jJFt/FyCowWkLQirUS9QhoGkf4xuXyb87cnBpl9BjENtgxk7A== X-Received: by 2002:a05:6402:3596:b0:447:11ea:362d with SMTP id y22-20020a056402359600b0044711ea362dmr20300404edc.117.1661858930658; Tue, 30 Aug 2022 04:28:50 -0700 (PDT) Received: from gazelle.gmail.com (p579ada31.dip0.t-ipconnect.de. [87.154.218.49]) by smtp.gmail.com with ESMTPSA id i12-20020a05640200cc00b00445b3cab975sm7139896edu.56.2022.08.30.04.28.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Aug 2022 04:28:50 -0700 (PDT) References: <87edwylxe9.fsf@gmail.com> <87y1v6ksmh.fsf@muradm.net> User-agent: mu4e 1.8.7; emacs 28.1.90 From: =?utf-8?Q?Th=C3=A9o?= Maxime Tyburn To: muradm Cc: guix-devel@gnu.org Subject: Re: Idea: Function composition to declare operating-system Date: Tue, 30 Aug 2022 12:52:33 +0200 In-reply-to: <87y1v6ksmh.fsf@muradm.net> Message-ID: <87ilmadl72.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=theo.tyburn@gmail.com; helo=mail-ed1-x536.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1661858946; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=XABJokzLHN9UcDKsHDDmZ4raTONwEeR6ikFwe/hJpFY=; b=WUJJWSOEu5wh+c2dqsTZxO63BTtTTvxxcO1QhJEcMMGllV57jp9Pnam73DvdJ3u/A5QwSi B9o2VpVWIpTkG27rpOsoNLcK7ouRIUvx7BhknL2PXWXtJU+Pzvbljs0eJusRJ0Rnd8oUhF eeqgMTpSAc5/+0IGc1zgwlR/ygbkwvWtS8zJvasojCN9q+crp5ILxupln6L18Kk39Hhnhn y3/mPAIP/qAJCb5g22H4FmvKZtvliiAigs2Lh3wGx3rjm119MuJtP561lJswPlVp7nsAUH 4biMo+yfuW7MX1A3gDwgPqdrBV7FvmLOeDX05B9CfqxPkTVVZ77EmUHSwpF3dQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661858946; a=rsa-sha256; cv=none; b=tYgwgCuRPXZGI4nYGcccyqdGraQkcRm0De7Ercvs9BCpkTcDpRzoNevUdG2K2zlhY7H4wr 8rm2LBSMFxj9Vcn09phh5FGD5kN/hA/90pF6JqD6+QYpok+negNZlGsru/BW3n4ObGdNPk ZcaBd5u1yGrMDFLSM9i5RypS0O55uMYNcSjRiSJjrXnU946ilH2ebJCMuX0nx1KIZRCP8c ztIuGh03lilQeJOuvnt8jbkJuhxVxz5yz2vnVuIG/nJb/BonO1jG7hApl8a16vzJMrCuMN HaEZ6Ac73WeIR+tz3UXvAUb2AopBjOsrVtfe/oiXajJdp/MtQ9JpYOkGm+8pRA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GBaUrJxl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -9.59 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GBaUrJxl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 6C61016D3B X-Spam-Score: -9.59 X-Migadu-Scanner: scn0.migadu.com X-TUID: jShYfhSD0/ME Hi muradm! muradm writes: [...] >> --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=E2=80=99t it be better if I just had a function `add-jackd` t= hat >> 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. Actually I was thinking that the functions that build up the system like `add-jackd` would be written by users. It is still user configuration, just packaged in a function. So no one would "have to" maintain it. But this could still provide an easy way to share independent parts of a system configs. Especially for features requiring a complex setup, a canonical configuration could be something you would want = to maintain. But it would be up to the maintainer. Assuming tough, someone wants to maintain `add-jackd` under (gnu services ...), it should not be more maintenance effort than the effort each and every user of jackd has to put so that it=E2=80=99s system configuration doesn=E2=80=99t break. So I don=E2=80=99t see anything agains= t it. But I might be wrong. >> >> So that was the purpose of the experimentation. It didn=E2=80=99t turn o= ut >> 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. I agree, better make this optional. If anything, only this this kind of helper function would be added to guix so that users can define their system conveniently using this function composition approach.=20 >> 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. Yes you are right, that would also do the trick. There is actually no real need for the helper function defined above. One would just have to pass the list of service-types that gets duplicated to (delete TYPE) in modify-services. I am not aware of a way of deleting a list of service-types easily using modify-services without defining a macro though, so it seems you need some sort of helper function anyway. > Thanks in advance, > muradm Thanks for the return, Th=C3=A9o