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

[Blake Shaw]

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