From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHGUo-0003xK-2y for guix-patches@gnu.org; Sat, 03 Jun 2017 17:22:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHGUk-0000vZ-39 for guix-patches@gnu.org; Sat, 03 Jun 2017 17:22:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:51560) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHGUj-0000vS-VQ for guix-patches@gnu.org; Sat, 03 Jun 2017 17:22:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHGUj-000711-QK for guix-patches@gnu.org; Sat, 03 Jun 2017 17:22:01 -0400 Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170530215850.7522-1-ludo@gnu.org> Date: Sat, 03 Jun 2017 23:21:01 +0200 In-Reply-To: <20170530215850.7522-1-ludo@gnu.org> ("Ludovic \=\?utf-8\?Q\?Cour\?\= \=\?utf-8\?Q\?t\=C3\=A8s\=22's\?\= message of "Tue, 30 May 2017 23:58:50 +0200") Message-ID: <8737bgkbsy.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: 27155@debbugs.gnu.org Cc: Alex Kost Ludovic Court=C3=A8s skribis: > This patch adds support for service extensions that modify the > "final" values of a service. This is meant to implement cross-cutting > concerns as well as system-wide customization as discussed with Alex > long ago: > > https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00623.html > https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html > > To summarize, a "finalization extension" (for lack of a better name) > gets the final value of a service and returns a new value for that > service. I found a better name: =E2=80=9Ccustomizations=E2=80=9D. > For example, for the /etc service, a "normal" extension can only add > entries for /etc. A "finalization" extension can instead inspect and > change all the /etc entries. IOW, it is a sort of a "sudo" for service > extensions; it's also quite inelegant compared to the "normal" extension > mechanism, but it's certainly useful. Not liking the =E2=80=9Csudo=E2=80=9D aspect of this patch, I thought it wo= uld be natural if service types could control how customizations apply. That way, the PAM or /etc service could still guarantee, for instance, that customization does not add or remove entries, and so on. In the end, this control by the service type makes it easier to reason about what extensions do, whereas the =E2=80=9Csudo=E2=80=9D style means th= at an extension can alter the service=E2=80=99s value in any possible way. So I started modifying this patch set to add a =E2=80=98customize=E2=80=99 = field to , next to =E2=80=98extend=E2=80=99. For the PAM and /etc ser= vices, =E2=80=98customize=E2=80=99 would compose and apply procedures that modify = an entry, for instance. Then I realized that the only difference between =E2=80=98customize=E2=80= =99 and =E2=80=98extend=E2=80=99 would be the meaning attached to it. IOW, both ar= e some kind of an extension. So at this point, I started wondering whether we should just allow service types to declare several extension points. So for PAM, we=E2=80=99= d do: --8<---------------cut here---------------start------------->8--- (define pam-service-addition ;; The extension point to add PAM services. (service-extension-point (compose concatenate) (extend append))) (define pam-service-cutomization ;; The extension point to customize PAM services. (service-extension-point (compose compose) (extend append))) (define pam-root-service-type (service-type (name 'pam) (extensions (list (service-extension etc-service-type /etc-entry))) (extension-points (list pam-service-addtion pam-service-customization)))) --8<---------------cut here---------------end--------------->8--- But then =E2=80=98service-extension=E2=80=99 would need to specify not only= the target service type but also the target extension point, which means more boilerplate, etc. So after so much thought and hacking, I feel like the ad hoc solution at was not that bad after all. Sorry to bother you with philosophical design questions when we already have two ways to solve the problem at hand, but I feel like there=E2=80=99s= a pattern worth looking for! Ludo=E2=80=99.