From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlo Zancanaro Subject: Re: Services can now have a default value Date: Thu, 20 Apr 2017 20:19:18 +1000 Message-ID: <874lxjnzyx.fsf@zancanaro.id.au> References: <87shl9qo7h.fsf@gnu.org> <877f2go3wn.fsf@zancanaro.id.au> <877f2gksbs.fsf@gnu.org> <8737d32abz.fsf@zancanaro.id.au> <87bmrr4ghh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d19BS-0001uv-DO for guix-devel@gnu.org; Thu, 20 Apr 2017 06:19:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d19BO-0003Uy-9M for guix-devel@gnu.org; Thu, 20 Apr 2017 06:19:30 -0400 In-reply-to: <87bmrr4ghh.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey Ludo, 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. One nice thing about this approach is that now a "service type" is a scheme record-type, and a "service" is a particular instance of that record-type, which feels slightly simpler/cleaner to me. > Or we could make =E2=80=9Cstruct vtables=E2=80=9D and then= make > instances of those vtables (info "(guile) Vtables"). > I=E2=80=99d rather avoid using those interfaces, though (currently the on= ly > record API we use is SRFI-9.) I don't know what this means. I had a quick scan of the documentation, but I'll have to read it in more detail later. > Or we could have a =E2=80=98define-service=E2=80=99 macro that defines bo= th the > and the , and defines a =E2=80=98foo-se= rvice=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. 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. > I=E2=80=99m not sure what you mean. Is it something like what =E2=80=98s= imple-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. I don't think that's a good idea, though. Carlo --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEwWt2bKTcV+mIZ20oCShLEsLiKqIFAlj4iyYACgkQCShLEsLi KqK/tgf/eP1oLQUDXGYa1id+PcrWyceET+/Av18deFNoNvH/A8Wuw/iNbOCFpIFV FEMOZRbs9oqZtClub395WBYRoKIeryqrbEpVhOQVHmHn//qyKGZIRdk+KOWdAWub RoUDVFRW7MpNov0i5mQDjPhMyfostKRm4bi6S1lhzwe4V9HDXVlQr7c5LV81k7Ql IHHjN+q0HiP60qvdc5D6BhJhRUFu2pfC48IxaUvwqRlZ7iy3ch1TUYZ6f+kM6SqV 5MiJzEVFQgcHVF/TZjhYU89JY5gD55ICZLw4jaFRZNhl+3TRUIF0ms7CkcK6KLcG T2kasLRVvE+EKkA9fFJkrrfInrtIeg== =yr1X -----END PGP SIGNATURE----- --=-=-=--