Hi Carlo,
Carlo Zancanaro <ca...@zancanaro.id.au> skribis:
>> 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! :-)).
>
> Could we create a mapping from configuration -> service-type? Or somehow
> embed the service-type inside the configuration record? (I prefer the
> former.) That way we could specify our service list as a list of
> configurations without having to doubly-specify the services.
>
> So then instead of
>
> (service foo-service-type
> (foo-configuration (foo #f)
> (number 42)))
>
> we could have:
>
> (foo-configuration (foo #f)
> (number 42))
>
> and have the foo-service-type implicitly looked up when instantiating
> the services.
There must be some sort of a mapping between service types and
configuration types, indeed, but I’m not sure how to achieve it.
One solution would be to have all the <foo-configuration> records
inherit (in the OO sense) from <service>, or something along these
lines.
Or we could make <service-type> “struct vtables” and then make
<foo-configuration> instances of those vtables (info "(guile) Vtables").
I’d rather avoid using those interfaces, though (currently the only
record API we use is SRFI-9.)
Or we could have a ‘define-service’ macro that defines both the
<service-type> and the <foo-configuration>, and defines a ‘foo-service’
macro equivalent to (service foo-service-type (foo-configuration …)).
(define-service-type openssh-service-type
openssh-service
(extensions …)
(configuration
(port openssh-service-port (default 22))
(use-pam? openssh-service-use-pam? (default #t))))
and then:
(operating-system
;; …
(services (cons (openssh-service (port 2222)) %base-services)))
Thoughts?
>> The default value thing in this thread is about making the ‘service’
>> form less verbose and closer to what we had with ‘-service’
>> procedures.
>
> Yeah, okay. I guess I just saw the change and felt like it doesn't
> actually change much. Having a default value saves you a bit of typing,
> but only in the case where you don't want to change any configuration
> for the service.
>
> The other thing that it would buy you (which is more significant) is the
> ability to create services that are required for service extensions, but
> which aren't listed in the operating-system's services. I assume we
> don't want to do that, though, because that could be
> dangerous/surprising.
I’m not sure what you mean. Is it something like what ‘simple-service’
does?
>> Does that clarify things?
>
> Yes, thanks! Are there discussions somewhere that I can read about how
> this came together? I don't think I've been on the list long enough to
> have seen it myself (or if I have, I can't find them).
It all started with the new service API, which introduced service types
and service objects:
https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00608.html
The specific issue we’re discussing hasn’t received much attention
though, but it’s been discussed a few times as people were adding new
service definitions.
Thanks,
Ludo’.
