Services and access to the global configuration

[Ludovic Courtès]

宋文武 <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> 宋文武 <address@hidden> skribis:
>>
>>> Ludovic Courtès <address@hidden> writes:
>>>
>>>> Adam Pribyl <address@hidden> skribis:

[...]

>>> I just put it in my config.scm:
>>>
>>>   (define (console-layout-service layout)
>>>     (with-monad %store-monad
>>>      (return
>>>       (service
>>>        (document "Setup keyboard layout for console")
>>>        (provision '(console-layout))
>>>        (start #~(lambda _
>>>                   (system* (string-append #kbd "/bin/loadkeys") #$layout)))
>>>        (stop #~(const #t))
>>>        (respawn? #f)))))
>>
>> Excellent.  I was thinking that we should have a keyboard layout setting
>> in the OS declaration, that would lead to a service like the one above
>> as well as the appropriate X settings.
> Currently, operating-system is not declarative, with the setting:
>   (operating-system
>     (keymap "dvorak"))
> IIUC, the xorg-server service can't see it unless passed explicitly.

Right.

> In NixOS, declarative configuration is implemented by 'modules':
>   https://nixos.org/wiki/NixOS:Modules
>   
> Every module can define some options, access and contrib to the config,
> the configuration.nix is just a normal module provided by user.
>
> Yeah, how all the modules eval toghether is still a mystery for me.

Yes, that’s the whole point.  I don’t want an ‘mkIf’ here.  ;-)

There are several issues here.

  1. Is it desirable for any service to be able to touch any part of the
     OS configuration, as is the case in NixOS?  I’m not sure.  On one
     hand, it’s useful in situations like the one above; on the other
     hand, it feels like each service definition would get more
     authority than it really needed.

     Currently, the <service> type has fields such as ‘user-accounts’
     and ‘pam-services’ for that reason: a service can add new accounts
     or PAM services, but does not access the global OS config.  These
     would not be needed if services had access to the global config.

  2. Services typically need to be able to add files to the store, etc.
     Currently, that means that services must be monadic values in the
     store monad.

     This is slightly annoying, because indeed it makes it feel “less
     declarative.”

  3. In NixOS there’s no type checking: one can just add fields to the
     global configuration attribute set, and they may be picked up by
     service definitions.

     Here, ‘operating-system’ is a well-defined type, and
     service-specific options are passed as arguments to procedures that
     implement the service.

Just random thoughts.  :-)

I feel there are things we can improve, but it’s not completely clear
how yet.

Thanks,
Ludo’.