GNU bug report logs - #62401
[PATCH] home: Add home-syncthing-service-type.

Previous Next

Full log

View this message in rfc822 format

From: Bruno Victal <mirai <at> makinata.eu>
To: Ludovic Courtès <ludo <at> gnu.org>, Sergey Trofimov <sarg <at> sarg.org.ru>
Cc: guix-devel <at> gnu.org, paren <at> disroot.org, 62401 <at> debbugs.gnu.org, andrew <at> trop.in
Subject: [bug#62401] Automatically mapping services from System to Home
Date: Wed, 29 Mar 2023 16:21:02 +0100

Hi Ludo’,

On 2023-03-28 17:18, Ludovic Courtès wrote:
> One idea I toyed with is automatic translation of service types from
> System to Home.  The service itself would look like this:
> 
> --8<---------------cut here---------------start------------->8---
> (define-module (gnu home services syncthing)
>   #:use-module (gnu home services)
>   #:use-module (gnu services syncthing)
>   #:export (home-syncthing-service-type)
>   #:re-export (syncthing-configuration
>                syncthing-configuration?))
> 
> (define home-syncthing-service-type
>   (system-service-type->home-service-type syncthing-service-type))
> --8<---------------cut here---------------end--------------->8---
> 
> The code to do that is attached below.  The key here is that we’d define
> mappings, like:
> 
>   (define-service-type-mapping
>     shepherd-root-service-type => home-shepherd-service-type)
> 
> The rest of the service type graph would be automatically constructed
> from this.
> 
> I feel like it would be worth pursuing this path so that there’s as
> little duplication as possible between Home and System.
> 
> OTOH, it doesn’t take care of things like #:user in
> ‘make-forkexec-constructor’ calls and the like.
> 

I've been thinking that shepherd services should, in general, come with a
preamble in their configuration record-types. (perhaps à la SRFI-136 parent-style records?)

Below is a non-exhaustive list of “things” that should almost always be configurable,
unless it's reasonable to omit it:

--8<---------------cut here---------------start------------->8---
;; These fields were listed based on “experience” in reworking,
;; repurposing and adding new (system) services within Guix.


(define-configuration example-configuration
  ;; Allow the package to be overridden.
  (package
    file-like
    "Lorem ipsum …")

  ;; Note that they're not strings. This allows for tailoring
  ;; the user-account used by the service (e.g. adding extra groups
  ;; for the daemon to have access to other directories, etc.
  (user
    user-account
    "Lorem ipsum …")

  ;; ^^^^^ Ditto.
  (group
   user-group
   "Lorem ipsum …")

  (shepherd-requirement   ; or shepherd-requirements, the former already has some presence in Guix
                          ; but could be phased-out in favor of the plural form
    list-of-symbols
    "Lorem ipsum …")

  ;; Uncommonly seen among services
  ;; but mpd-service-type is an example where this is important.
  (environment-variables
    list-of-env-vars
    "Lorem ipsum …")

--8<---------------cut here---------------end--------------->8---


Tossing another idea in the air, with <https://issues.guix.gnu.org/62298>
define-configuration could perhaps be enriched with additional parameters to 
hint that certain fields should be treated differently depending
on “context”? Naturally the service code will have to be adjusted
to use these hints, but overall it should result in a much cleaner
way to guide serializations and service-extension pruning.


It could be something of the sort:

--8<---------------cut here---------------start------------->8---
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
   (attributes 'system-service)
  …)

;; or
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
    system-only
  …)


;; or
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
    (system #t)
    (home #f)
  …)
--8<---------------cut here---------------end--------------->8---


Cheers,
Bruno

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.