Re: Updates on the guix home manager

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Julien!

Julien Lepiller <julien@lepiller.eu> 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