From: ludo@gnu.org (Ludovic Courtès)
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Services can now have a default value
Date: Thu, 20 Apr 2017 10:42:50 +0200 [thread overview]
Message-ID: <87bmrr4ghh.fsf@gnu.org> (raw)
In-Reply-To: <8737d32abz.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Thu, 20 Apr 2017 10:26:24 +1000")
Hi Carlo,
Carlo Zancanaro <carlo@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’.
next prev parent reply other threads:[~2017-04-20 8:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 22:51 Services can now have a default value Ludovic Courtès
2017-04-15 23:11 ` ng0
2017-04-17 11:56 ` Ricardo Wurmus
2017-04-19 23:22 ` ng0
2017-04-20 8:53 ` Ricardo Wurmus
2017-04-20 9:09 ` ng0
2017-04-23 10:23 ` Ricardo Wurmus
2017-04-17 11:58 ` Ricardo Wurmus
2017-04-19 14:42 ` Carlo Zancanaro
2017-04-19 15:18 ` ng0
2017-04-19 21:20 ` Ludovic Courtès
[not found] ` <8737d32abz.fsf@zancanaro.id.au>
2017-04-20 8:42 ` Ludovic Courtès [this message]
2017-04-20 10:19 ` Carlo Zancanaro
2017-04-21 22:04 ` Ludovic Courtès
2017-04-21 23:41 ` Carlo Zancanaro
2017-04-22 0:46 ` We need an RFC procedure [Re: Services can now have a default value] ng0
2017-04-22 7:12 ` Ricardo Wurmus
2017-04-22 10:08 ` ng0
2017-04-22 22:55 ` Ludovic Courtès
2017-04-23 10:13 ` Ricardo Wurmus
2017-04-23 12:02 ` ng0
2017-04-27 13:29 ` Ludovic Courtès
2017-04-27 16:37 ` Petter
2017-05-02 12:42 ` Ludovic Courtès
2017-05-22 21:23 ` Ricardo Wurmus
2017-05-22 22:45 ` Leo Famulari
2017-04-23 11:52 ` ng0
2017-05-13 10:39 ` Services can now have a default value Carlo Zancanaro
2017-05-13 22:53 ` Carlo Zancanaro
2017-05-15 12:48 ` Ludovic Courtès
2017-04-22 14:46 ` Christopher Allan Webber
2017-04-22 14:59 ` Jan Nieuwenhuizen
2017-04-22 22:57 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmrr4ghh.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=carlo@zancanaro.id.au \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).