Guix shepherd user services

[Pierre Neidhardt <mail@ambrevar.xyz>]

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

I've been thinking about shepherd user services.

We just had a discussion on the topic:

	https://lists.gnu.org/archive/html/help-guix/2019-02/msg00010.html

and an interesting patch was sent a while ago:

	https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00047.html.

Jelle first introduced me to this idea during the Guix days and it took
me a while to understand why it's pure awesomeness.  In short: just like
we can fully configure an operating-system in Guile and we don't have to
touch /etc manually, we could do the same with our user profile.  At
last, done with .bashrc / .profile to start user daemons, cron jobs,
whatever synchronization script you use...

It would also make it possible to fully _initialize_ a user profile (just like
we initialize the operating-system) with the desired files.  For instance, a
service could synchronize git repositories (e.g. your dotfiles), deploy it,
synchronize your emails, generate the mlocate cache, snapshot some btrfs drives,
you name it.

As a result, on a Guix install it would be possible to run

	guix service --install -f my-services.scm

let the magic happen, relog(?) et enjoy a 100% pre-configured user
profile.  How cool is that?

Benefits over traditional dotfiles or cron jobs:

- No more need for .xinitrc, .local/bin, etc.

- Declarative and uniformly programmable in Guile.

- Every service is uniformly controllable (start, restart, stop, status, etc.).
  It's not so convenient to do that with a daemon that was started from .xinitrc.

- Drags non-propagated inputs automatically, no need to polute the user profile
  (e.g. with redshift, xcape, etc.)

- Pre-configured services to choose from, as provided by Guix (unlike mcron).


My thoughts regarding the implementation design:

- Services can be enabled, disabled, started, restarted, stopped, listed,
  they can show details and documentation, they can run pre-defined actions.
  They are semantically very different from packages (in fact they often use
  packages, but not always).  I don't think it would be good to mix and match
  services and packages in a command like `guix package --list-installer`.  So I
  suggest we keep them separate.

- The user must be able to build and install services.  We could have the
  following behaviour then:

  `guix service --build redshift` would produce a
  /gnu/store/...-shepherd-redshit.scm

  `guix service --install redshift` would install it to ~/.guix-profile/services/redshift.scm.

  `guix service --remove redshift` would remove it from the above location.

  `guix service --upgrade=redshift` would rebuilt the service (and maybe
  redshift) and install the new version.

- How do we write custom services?  Well, just like we write custom packages and
  custom operating-system, in a channel or in GUIX_PACKAGE_PATH (which name
  becomes less and less meaningful).

- How do we update services (e.g. the redshift service when the redshift package
  just got updated)?  My understanding is that services are citizens similar to
  operating system declarations: they depend on the current Guix version and the
  user-defined definitions (e.g. channels).
  Then `guix pull && guix service --upgrade` will do.

- How do we start the user shepherd on login and load the service configuration?
  We need to be cautious to support foreign distributions.  On GuixSD, we could
  arrange /etc/profile to run

    shepherd --config ~/.guix-profile/service-manifest.scm

  on login.  On foreign distributions, users can add the above command to
  ~/.profile, or ~/.bashrc, etc.

- If the package manifest and the service manifest are separate, it follows that
  we now have 2 parameters to "reproducibly" define a user profile.  I think
  that's fine and it allows for composition (mix and match service manifests and
  package manifests).

- Currently I think it's not possible to just define shepherd services without
  enabling them.  Thus it's not possible to have a list of available services
  just like we have a list of packages.  While this might be OK for the system
  (but is it?), I think it would be nice if, as a user, we could do a

      guix service --list-available

  and pick services from there.  This is somewhat a separate issue but
  it would be nice to solve it.  I don't know enough about the shepherd
  internals to go into the details here.

- Should Guix drive the services with a `guix service` subcommand or should we
  leave it to `herd` run by the user?  Since we use `herd` for system services,
  I think it's more consistent to stick to `herd`.

I'd like to work on it with anyone interesting on the topic.  I know
some people I've worked on it before, so feel free to share your
progress :)

--
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]