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: Wed, 19 Apr 2017 23:20:23 +0200 Message-ID: <877f2gksbs.fsf@gnu.org> References: <87shl9qo7h.fsf@gnu.org> <877f2go3wn.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]:52242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0x1Z-0004br-OJ for guix-devel@gnu.org; Wed, 19 Apr 2017 17:20:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0x1W-00086P-J2 for guix-devel@gnu.org; Wed, 19 Apr 2017 17:20:29 -0400 In-Reply-To: <877f2go3wn.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Thu, 20 Apr 2017 00:42:00 +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 Hi! Carlo Zancanaro skribis: > I have a question related to this, but about a broader issue. > > On Sat, Apr 15 2017, Ludovic Court=C3=A8s wrote: >> (service openssh-service-type) > > Is this supposed to be the preferred way to add a service to your > operating system? Or, put another way, as a service writer: should I > consider a *-service-type to be sufficient to complete the work of > creating a service? Yes. > Looking at various services that we have defined at the moment > (according to what is documented), most services have a procedure (ie. > *-service), and maybe also a *-service-type. For example, in "Database > Services" we have postgresql-service and mysql-service, with no > corresponding *-service-type. But then we have redis-service-type > without a *-service to go with it. > > I wonder if we would be better off creating *-service procedures for > each *-service-type and documenting them as the canonical way to create > services. That way we could handle things like default arguments through > the usual scheme mechanisms, rather than our own special case. It used to be that we would write =E2=80=98-service=E2=80=99 procedures. T= hen when (gnu services) was added, each of these procedures would boil down to: (define (foo-service #:key (foo foo) (number 42)) (service foo-service-type (foo-configuration (foo foo) (number number)))) There are two issues here: 1. The default values here are redundant with those we also specify in . 2. The =E2=80=98-service=E2=80=99 procedures are a bit opaque. For thing= s like =E2=80=98modify-services=E2=80=99, we want to expose the fact that we = have service objects with an associated value, rather than hide it inside a procedure. For these reasons, I=E2=80=99ve been progressively suggesting that we avoid =E2=80=98-service=E2=80=99 procedures altogether, and deprecate the existin= g ones. There are still many of them though, as you write; we should remove them (patches welcome! easy task for a GuixSD newcomer! :-)). The default value thing in this thread is about making the =E2=80=98service= =E2=80=99 form less verbose and closer to what we had with =E2=80=98-service=E2=80=99= procedures. Clearly there=E2=80=99s a parallel between procedures with keyword paramete= rs and services/configurations records with default field values. The key here is that we want first-class objects that we can inspect and derive from when customizing a system. Does that clarify things? Thanks, Ludo=E2=80=99.