Christopher Allan Webber <cweb...@dustycloud.org> writes: > Christopher Allan Webber writes: > >> Hello, >> >> I'm writing a service for dirvish, and I realized that if I'm following >> current guix service routes, I might not be able to run all the >> operations I need to.
Why not? I read the rest of your email but this wasn't clear to me. >> It seems that the current route for Guix is to have your service >> write out a config that more or less becomes part of the environment >> for starting / stopping a daemon via Shepherd. But what if that's >> not all you need to do? >> >> Aside from just "running as a daemon", plenty of (especially >> applications which manage state) will need to have other commands that >> are unlikely to be run from shepherd. For example: >> >> - Initializing a data store. For example, in dirvish I need to run >> a command to initialize a "vault" where I will be storing my data. >> - Manually invoking a garbage collection utility. >> - Manually invoking an integrity check utility. >> - Possibly some side effect involving querying the network. >> - Running schema migrations. >> >> All sorts of things! Most of them (all?) involve state or side effects, >> but plenty of our most important services will be "state overlords" of >> some type. Why do those activities need to be represented as actions in Shepherd? If we're running a daemon or service that already exposes a mechanism for manually running tasks like these, then can't we just use "the usual mechanism" for doing it? For example, if we're running a daemon that already provides a script to perform garbage collection, can't we just invoke that script? It isn't clear to me why we would need to model domain-specific actions like that in Shepherd, although I can see why it might be convenient. Am I missing something? -- Chris
signature.asc
Description: PGP signature
