[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Services can now have a default value
From: |
Ludovic Courtès |
Subject: |
Re: Services can now have a default value |
Date: |
Wed, 19 Apr 2017 23:20:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi!
Carlo Zancanaro <address@hidden> skribis:
> I have a question related to this, but about a broader issue.
>
> On Sat, Apr 15 2017, Ludovic Courtès 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 ‘-service’ procedures. Then 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
<foo-configuration>.
2. The ‘-service’ procedures are a bit opaque. For things like
‘modify-services’, we want to expose the fact that we have service
objects with an associated <foo-configuration> value, rather than
hide it inside a procedure.
For these reasons, I’ve been progressively suggesting that we avoid
‘-service’ procedures altogether, and deprecate the existing 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 ‘service’
form less verbose and closer to what we had with ‘-service’ procedures.
Clearly there’s a parallel between procedures with keyword parameters
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’.
Re: Services can now have a default value, Ricardo Wurmus, 2017/04/17
Re: Services can now have a default value, Carlo Zancanaro, 2017/04/19
- Re: Services can now have a default value, ng0, 2017/04/19
- Re: Services can now have a default value,
Ludovic Courtès <=
- Re: Services can now have a default value, Carlo Zancanaro, 2017/04/19
- Re: Services can now have a default value, Ludovic Courtès, 2017/04/20
- Re: Services can now have a default value, Carlo Zancanaro, 2017/04/20
- Re: Services can now have a default value, Ludovic Courtès, 2017/04/21
- Re: Services can now have a default value, Carlo Zancanaro, 2017/04/21
- We need an RFC procedure [Re: Services can now have a default value], ng0, 2017/04/21
- Re: We need an RFC procedure [Re: Services can now have a default value], Ricardo Wurmus, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], ng0, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], Ludovic Courtès, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], Ricardo Wurmus, 2017/04/23