guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Composing service definitions (and maybe fmt)


From: Christopher Allan Webber
Subject: Re: Composing service definitions (and maybe fmt)
Date: Thu, 21 Jan 2016 13:57:18 -0800

Ludovic Courtès writes:

> "Thompson, David" <address@hidden> skribis:
>
>> On Wed, Jan 20, 2016 at 5:13 PM, Ludovic Courtès <address@hidden> wrote:
>>
>>> To me, the question is more about choosing between writing configuration
>>> file bindings and exposing upstream’s configuration file syntax, as was
>>> discussed when Andy posted the Dovecot service.  (To which I don’t have
>>> a better answer than: let’s see on a case-by-case basis.)
>>
>> How about this:
>>
>> Procedures that return services should accept file-like objects when
>> configuration files are needed.  When it makes sense (like with
>> elogind, dovecot, etc.), we can provide special procedures that take a
>> Scheme data structure and "compile" that to a file-like object in the
>> service's native configuration language.  This way, we allow ourselves
>> to have the high-level Scheme configuration APIs we like while also
>> allowing the use of "raw" configuration files in situations where it
>> is unavoidable or the path of least resistance.
>
> I like it!  When we provide Scheme data structures, we necessarily have
> a ‘foo-configuration->file’ procedure anyway, so it’s just a matter of
> exposing it.
>
> Ludo’.

I like it, and have been thinking similar things... except... except!

You may remember my post to the list about how I'm interested in
service configurations which know about each others' variables.  I wrote
about why I think this is really important to solving deployment here:

  http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00736.html

If we build procedures which go from procedure inputs -> text and that's
all that gets passed to the service, do we lose the ability to
introspect the arguments being used to set up the service?

Would it be possible to have services which themselves set up services?
Eg, imagine I had something imaginary like:

  (3dprinter-service
   #:model "lawlsbot-3000"
   #:fill-pattern "hex")

(Ignore whether or not this is a sane way to configure a 3d printer at
all at the moment, I'm just making something up)

So, this might actually build the "implied" service of:

  (3dprinter-raw-service
   "[printconfig]
model = lawlsbot-3000
fill-pattern = hex")

... this way, daring users can provide their own config file if our
config file builders aren't good enough, but it's still possible to
have some other service or tool read that the 3dprinter-service has a
model with lawlsbot-3000, so it can show it in a menu, or something.

Is this possible, or even sane? :)

 - Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]