Re: how to write services (was: Re: Teams)

[Blake Shaw <blake@sweatshoppe.org>]

[-- Attachment #1: Type: text/plain, Size: 4205 bytes --]

Ricardo:
Thats very good advice and will be a useful guide in refactoring the parts
of the system services documentation. I think in general, we need to find a
nice middle ground between the extremely general and the immediately
sensible, as I remember when I first got into guix 1.5 years ago, arriving
at services left me very confused. While as a recent PhD candidate in
philosophy of mathematics I'm a fellow appreciator of the power of
generality (the extreme genericity of scheme and guix is why I'm here!), I
also think if it doesn't obey strict linguistic rules it can antithetical
to its original purpose. For example, I remember being very confused about
"file-like objects", for the simple reason that it wasn't "a file or
file-like object". While this might come from a GNU terminological lineage
i'm unaware of, my immediate reaction to trying to understand file-likeness
is the simple rule that a semblance is strictly not what it resembles, and
likeness qualifies semblance. It would be improper to place phones in a
category of "phone-like objects", because the likeness assumes a
distinction from the thing itself. Perhaps it could be justified if we dive
into the minutiae of paraconsistent logic, but I think then we are going to
far (also, isn't 'everything a file' a motto of Unix, even if gnu is
strictly not?). But I've digressed; I think your straightforward
description above communicates many of the ideas better than the docs, but
I think this is a situation where we can have our cake and eat it too, so
to speak; usually, an appendage such as "file AND file-like objects" will
accomplish much of the work for us.

Catonano:
I think writing a home-service is much easier given that you don't need to
do produce an entire system generation before you find out what you did
wrong; it just depends on if you need your service initialized at startup
(system-services, globally defined and available prior to login) rather
than at login (home-services, per-user/locally defined).

I'm not on Mastodon but feel free to send your service my way for some
help, I'm still a beginner but a second pair of eyes is always nice to have.

ez,
b


---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---


On Wed, Jun 15, 2022 at 2:04 PM Ricardo Wurmus <rekado@elephly.net> wrote:

>
> catonano@gmail.com writes:
>
> > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> >>
> >> I found the documentation to be a bit confusing (understandably, as
> >> its new), but once the workflow snapped together its been amazing to
> >> see how easy it is to create new services.
> >
> > This is something I'm specifically interested in
> >
> > In fact, I wrote this toot that got several boosts and likes but NO
> > answer
> > https://floss.social/web/@abbienormal/108378060174601402
>
> I don’t know Odoo, but the general process is this:
>
> - look up the relevant documentation of your application to figure out
>   what commands must be executed.  Take note of any way to pass a
>   configuration file.
>
> - copy an existing shepherd service.  Maybe start with
>   gnu/services/audio.scm, because it’s pretty simple while not completely
>   trivial.
>
> - adjust the commands and names.
>
> In gnu/services/audio.scm you see the definition of mpd-service-type,
> which is a *system* service that 1) adds a user account, 2) does some
> one-shot preparation work, and 3) registers the mpd-shepherd-service.
>
> mpd-shepherd-service is a procedure returning a shepherd service.  The
> service has a start and stop command.  Adjust this for your service.
>
> mpd-shepherd-service refers to its argument “config”, which is supposed
> to be a Scheme configuration value.  It’s just a record defined higher
> up as <mpd-configuration>.  mpd-config->file turns that Scheme value
> into a string that can live in a file as the mpd configuration file.
>
> This is pretty much all there is to it.  Some services are simpler and
> don’t need any one-shot setup, nor do they need system user accounts, so
> they would just boil down to a shepherd service definition.
>
> --
> Ricardo
>

[-- Attachment #2: Type: text/html, Size: 5153 bytes --]