From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Lepiller Subject: Updates on the guix home manager Date: Thu, 19 Sep 2019 23:22:57 +0200 Message-ID: <20190919232257.671511bb@sybil.lepiller.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54355) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iB40v-0000OR-6n for guix-devel@gnu.org; Thu, 19 Sep 2019 17:30:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iB40s-00038l-DL for guix-devel@gnu.org; Thu, 19 Sep 2019 17:30:56 -0400 Received: from lepiller.eu ([2a00:5884:8208::1]:56100) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iB40q-0002lx-LJ for guix-devel@gnu.org; Thu, 19 Sep 2019 17:30:53 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 44d717c5 for ; Thu, 19 Sep 2019 21:23:02 +0000 (UTC) Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 35b047fe (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Thu, 19 Sep 2019 21:23:02 +0000 (UTC) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org 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 :)