unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Julien Lepiller <julien@lepiller.eu>
Cc: guix-devel@gnu.org
Subject: Re: Updates on the guix home manager
Date: Tue, 24 Sep 2019 09:56:11 +0200	[thread overview]
Message-ID: <87k19ynn50.fsf@gnu.org> (raw)
In-Reply-To: <20190919232257.671511bb@sybil.lepiller.eu> (Julien Lepiller's message of "Thu, 19 Sep 2019 23:22:57 +0200")

Hello!

Julien Lepiller <julien@lepiller.eu> skribis:

> 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 ^^).

Nice!

Thinking out loud, this makes me wonder whether we should explore ways
for each user to be running its own sub-Guix System.  Like we’d spawn a
Guix System container the first time a user logs in, and all the user
processes would run in there, and the user would be able to reconfigure
that system.  That system’s PID 1 could spawn user processes.  That
wouldn’t address application configuration like Guix Home does, though.

> 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).

This is exactly what came to mind!  We discussed a similar idea in
<https://issues.guix.gnu.org/issue/27155> but that didn’t come to
fruition.

We should try and see whether/how to add the extension points you’ve
implemented in the service infrastructure, WDYT?

Anyway, Guix Home is really cool and it’d be great to provide something
along these lines out-of-the-box with Guix.  I still find the read-only
home approach somewhat too radical, but maybe I’m not daring enough.
;-)

Thanks!

Ludo’.

  parent reply	other threads:[~2019-09-24  7:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 21:22 Updates on the guix home manager Julien Lepiller
2019-09-20  9:31 ` Thorsten Wilms
2019-09-20 14:39   ` Julien Lepiller
2019-09-20 11:50 ` Maxim Cournoyer
2019-09-24  7:56 ` Ludovic Courtès [this message]
2019-09-25  9:41   ` Konrad Hinsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k19ynn50.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).