From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: Updates on the guix home manager Date: Fri, 20 Sep 2019 20:50:16 +0900 Message-ID: <87h8576vbb.fsf@gmail.com> References: <20190919232257.671511bb@sybil.lepiller.eu> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40296) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBHQi-00021b-6w for guix-devel@gnu.org; Fri, 20 Sep 2019 07:50:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBHQg-0002tN-KO for guix-devel@gnu.org; Fri, 20 Sep 2019 07:50:28 -0400 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]:35244) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iBHQg-0002rS-6e for guix-devel@gnu.org; Fri, 20 Sep 2019 07:50:26 -0400 Received: by mail-pf1-x442.google.com with SMTP id 205so4371224pfw.2 for ; Fri, 20 Sep 2019 04:50:23 -0700 (PDT) In-Reply-To: <20190919232257.671511bb@sybil.lepiller.eu> (Julien Lepiller's message of "Thu, 19 Sep 2019 23:22:57 +0200") 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: Julien Lepiller Cc: guix-devel@gnu.org Hi Julien! Julien Lepiller writes: > 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. That sounds really good! It might be a good replacement to my current use of GNU Stow. I'll try it. It'll be also my first real use of a Guix channel. [...] > 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. That indeed sounds convenient! The alternative would be to explicitly list every other "services" that must be extended? That has the merit to be explicit (and already available in Guix?), but could quickly become burdensome, I guess. > 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). As I read this I'm thinking it'd be desirable to extend what's already in Guix rather than having lots of duplicated code. I'll let other more knowledgeable about services to chip in about whether the new "service point" idea could be integrated in Guix proper. Thanks for this interesting work :-) Maxim