From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Services can now have a default value Date: Sat, 22 Apr 2017 00:04:09 +0200 Message-ID: <87bmrp8lk6.fsf@gnu.org> References: <87shl9qo7h.fsf@gnu.org> <877f2go3wn.fsf@zancanaro.id.au> <877f2gksbs.fsf@gnu.org> <8737d32abz.fsf@zancanaro.id.au> <87bmrr4ghh.fsf@gnu.org> <874lxjnzyx.fsf@zancanaro.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1gf3-00060y-Ei for guix-devel@gnu.org; Fri, 21 Apr 2017 18:04:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1gey-0001Ld-Q1 for guix-devel@gnu.org; Fri, 21 Apr 2017 18:04:17 -0400 In-Reply-To: <874lxjnzyx.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Thu, 20 Apr 2017 20:19:18 +1000") 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+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Carlo Zancanaro Cc: guix-devel Hello, Carlo Zancanaro skribis: > On Thu, Apr 20 2017, Ludovic Court=C3=A8s wrote: >> There must be some sort of a mapping between service types and >> configuration types, indeed, but I=E2=80=99m not sure how to achieve it. >> >> One solution would be to have all the records >> inherit (in the OO sense) from , or something along these >> lines. > > This was my first thought. I couldn't see how to do OO-style inheritance > with the SRFI-9 API, though. I'm not very experienced with Guile (or > scheme generally), so I might do some more reading about that. SRFI-99 supports inheritance, though there=E2=80=99s currently no SRFI-99 m= odule in Guile proper: https://srfi.schemers.org/srfi-99/srfi-99.html Oh and there=E2=80=99s also R6RS records, SRFI-35=E2=80=A6 no shortage of r= ecord APIs! :-) >> Or we could have a =E2=80=98define-service=E2=80=99 macro that defines b= oth the >> and the , and defines a =E2=80=98foo-s= ervice=E2=80=99 >> macro equivalent to (service foo-service-type (foo-configuration =E2=80= =A6)). >> >> (define-service-type openssh-service-type >> openssh-service >> (extensions =E2=80=A6) >> (configuration >> (port openssh-service-port (default 22)) >> (use-pam? openssh-service-use-pam? (default #t)))) >> >> and then: >> >> (operating-system >> ;; =E2=80=A6 >> (services (cons (openssh-service (port 2222)) %base-services))) > > I also thought about this, but I was concerned about things like > dovecot-service, where there are two configuration objects. I wouldn't > want to force us to duplicate code, and create two different service > types, if we wanted services like that in future. > > Although, maybe we would actually rather enforce a "one configuration > type per service type" rule, for the sake of modifying services? It's > hard to modify a service if you can't be sure of what the type of the > configuration will be. Right, I would prefer one type per service. I didn=E2=80=99t know dovecot = was different. > Do you have a preference for what approach to use? If we use a macro to > generate things then we retain the same flexibility as the current > approach which removing a bunch of boilerplate, but I'm not sure I have > the best view of the trade-offs involved. A =E2=80=98define-service-type=E2=80=99 macro or similar could generate eit= her code the current framework (with and and ) or for SRFI-99-style records if we later to go that route. So I think we should start by designing this macro. How does that sound? >> I=E2=80=99m not sure what you mean. Is it something like what =E2=80=98= simple-service=E2=80=99 >> does? > > I meant something more like what I did with exim-service-type, where I > extend a service just to ensure its presence, then I had to document > you have to have a mail-aliases-service-type in order to use exim. With > a default configuration the mail-aliases-service-type could be > automatically instantiated if it doesn't exist. Oh right. Well I don=E2=80=99t know, perhaps in some cases it might make sense to automatically instantiate things depended on. The advantage is that as a user of the service (exim for instance) you don=E2=80=99t have to be awar= e of the services it expects (improves separation of concern). So you could blissfully write just: (cons (service mediagoblin-service-type) %base-services) and behind the scenes it would add an nginx instance, an mcron instance with a couple of jobs, a rottlog instance, and so on. WDYT? Thanks, Ludo=E2=80=99.