Updates on the guix home manager

[Julien Lepiller]

Hi Guix!

I've recently been working a bit on my guix home manager
(https://framagit.org/tyreunom/guix-home-manager). The guix home
manager is taking the guix philosophy one step further: after
environment management, package management and operating system
management, here is the tool for managing your configuration files.
This tool will help you declare your home configuration, instead of
statefully mutating your files. Because applications tend to install
stuff anywhere in your $HOME, the directory is completely taken over by
guix and replaced by a symlink to a profile, which makes it read-only.
It means applications will not be able to create or change files, and
ensures that your configuration always stays the same. Guix home
manager brings the benefits of guix to your home directory: roll backs,
atomic updates, declarativity... It is however still a work in progress
and more of an experiment. That is why I keep it in a separate channel.

Some of the news include:

more configurations supported, although it's still very limited. I now
have configurations for hexchat, keepassxc, openbox and ssh as well as
some generic functions that can be used as an escape hatch for software
that is not yet configurable with services.

A new "guix home" subcommand, with support for "guix home build" (that
builds a home configuration), "guix home reconfigure" (that builds and
installs a new generation of the home configuration, and ensures that
$HOME is a symlink that points to it), and "guix home
list-generations" (that lists available generations). I'd like to add
more subcommands, taking inspiration from "guix system" (I copied a
lot of code from Guix ^^).

Initially, I implemented guix home with packages, then procedures that
returned file-like objects representing a part of the home files, then
they were merged together to form a package that was installed to form
a profile. This is not longer the case: guix home will not create a
package, but a proper profile.

Guix home now uses an infrastructure similar to the infrastructure for
services in Guix (I copied a lot of code from Guix for that feature
too). Home services are a bit different from Guix system services, and
I'd like to talk about that in the rest of this email.



As you probably know, guix services have an extension mechanism that
allows for instance to have a web service service declaration that
extends the nginx configuration with a new server block, so the web
server can serve the declared web service. All this, without the user
having to specify explicitely what they want. When the extended service
is not explicitely instantiated by the user, the service is implicitely
instantiated with its default value (if there is one, otherwise an
error is raised).

With guix home however, I wanted to experiment with a different
extension mechanism. You could call it an extension of extensions :D

When configuring your home directory, you would probably like to have
some consistent choices between different configurations. For instance,
I'm thinking about color themes of terminal applications. You probably
want all your configured terminals to use the same colors. I think it
would be convenient to provide one home service for each terminal from
which to choose. Say you have xfce4-terminal-home-type and
gnome-terminal-home-type, but didn't configure a
mate-terminal-home-type. You would like both terminals to have the same
color theme, but maybe the colors are not configured in the same way in
both service types.

I you have a color-theme-home-type that extends all terminals, color
themes would be configured in all terminals, but because of the
extension, a mate-terminal-home-type would be instantiated.

My version of services introduce the notion of an extension point: all
three terminal services would implement a color-theme extension point
that could be targeted by another service. When it targets an
extension point, a service does not need to specify what service is
extended. In that case, no service is implicitely instantiated, and any
service with that extension point is extended. This is exactly what we
want to do here: by using the extension point, without specifying a
target service, both gnome and xfce4 terminal configurations are
updated with your color theme, and mate-terminal-home-type is not
instantiated.

This kind of extension could also be useful for the web service example
we have seen: by creating an extension point in the nginx and apache
services, the web service could extend that extension point with a
value that would be translated into a server block or a virtual host,
depending on which server is installed. However, it does not work well
when no server is installed (because none is implicitely instantiated)
or when both are installed (they will both serve the same domain on the
same port).

OK, this email is already quite big, so I'm stopping right there.
Please tell me what you think, especially about this alternative
extension mechanism :)