* Updates on the guix home manager
@ 2019-09-19 21:22 Julien Lepiller
2019-09-20 9:31 ` Thorsten Wilms
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Julien Lepiller @ 2019-09-19 21:22 UTC (permalink / raw)
To: guix-devel
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 :)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Updates on the guix home manager
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
2 siblings, 1 reply; 6+ messages in thread
From: Thorsten Wilms @ 2019-09-20 9:31 UTC (permalink / raw)
To: guix-devel
On Thu, 19 Sep 2019 23:22:57 +0200
Julien Lepiller <julien@lepiller.eu> wrote:
> 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.
OK, let me try to put that in different terms:
An application-configuration may contain placeholders. A
generalized-configuration may declare that it fills in a specific
placeholder. This happens automatically, if the
generalized-configuration is used, while any
application-configuration with such a placeholder is also in use.
So basically like having an inherits-from, but with one level of
abstraction that allows to swap in the thing to inherit from?
So far, in my own practice, what I have been missing is a way to manage
defaults and customizations. I'd like to keep track of it, in terms of
"these are the defaults the application has been installed with",
"these are the changes I applied". Then, when an update of the
application does anything to the defaults, I want to be able to get to
a diff and the option to apply my changes as a patch, or see where
conflicts are.
Adding a mechanism to generalize settings, I can only imagine a graph,
consisting of generalized-settings-producers, translators, patches and
combiners. Actually, generalized-settings-producers could be patches
(from nothing to something).
--
Thorsten Wilms <t_w_@freenet.de>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updates on the guix home manager
2019-09-20 9:31 ` Thorsten Wilms
@ 2019-09-20 14:39 ` Julien Lepiller
0 siblings, 0 replies; 6+ messages in thread
From: Julien Lepiller @ 2019-09-20 14:39 UTC (permalink / raw)
To: guix-devel, Thorsten Wilms
Le 20 septembre 2019 11:31:15 GMT+02:00, Thorsten Wilms <t_w_@freenet.de> a écrit :
>On Thu, 19 Sep 2019 23:22:57 +0200
>Julien Lepiller <julien@lepiller.eu> wrote:
>
>> 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.
>
>OK, let me try to put that in different terms:
>An application-configuration may contain placeholders. A
>generalized-configuration may declare that it fills in a specific
>placeholder. This happens automatically, if the
>generalized-configuration is used, while any
>application-configuration with such a placeholder is also in use.
An extension changes the configuration value of a service. In the case of a web server, you can extend it multiple times to add more server blocks. Sometimes, it doesn't make sense to extend more than once, as in the color theme example. In that case, you can think of the extension as replacing a default value somewhere.
>
>So basically like having an inherits-from, but with one level of
>abstraction that allows to swap in the thing to inherit from?
It looks like multiple inheritence, indeed. Although, an extension-point can be extended multiple times.
>
>
>So far, in my own practice, what I have been missing is a way to manage
>defaults and customizations. I'd like to keep track of it, in terms of
>"these are the defaults the application has been installed with",
>"these are the changes I applied". Then, when an update of the
>application does anything to the defaults, I want to be able to get to
>a diff and the option to apply my changes as a patch, or see where
>conflicts are.
>
>Adding a mechanism to generalize settings, I can only imagine a graph,
>consisting of generalized-settings-producers, translators, patches and
>combiners. Actually, generalized-settings-producers could be patches
>(from nothing to something).
It is a graph! For guix system, you can see that with guix system extension-graph.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updates on the guix home manager
2019-09-19 21:22 Updates on the guix home manager Julien Lepiller
2019-09-20 9:31 ` Thorsten Wilms
@ 2019-09-20 11:50 ` Maxim Cournoyer
2019-09-24 7:56 ` Ludovic Courtès
2 siblings, 0 replies; 6+ messages in thread
From: Maxim Cournoyer @ 2019-09-20 11:50 UTC (permalink / raw)
To: Julien Lepiller; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updates on the guix home manager
2019-09-19 21:22 Updates on the guix home manager Julien Lepiller
2019-09-20 9:31 ` Thorsten Wilms
2019-09-20 11:50 ` Maxim Cournoyer
@ 2019-09-24 7:56 ` Ludovic Courtès
2019-09-25 9:41 ` Konrad Hinsen
2 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2019-09-24 7:56 UTC (permalink / raw)
To: Julien Lepiller; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updates on the guix home manager
2019-09-24 7:56 ` Ludovic Courtès
@ 2019-09-25 9:41 ` Konrad Hinsen
0 siblings, 0 replies; 6+ messages in thread
From: Konrad Hinsen @ 2019-09-25 9:41 UTC (permalink / raw)
To: Ludovic Courtès, Julien Lepiller; +Cc: guix-devel
Hi everyone,
>> A new "guix home" subcommand, with support for "guix home build" (that
>> builds a home configuration), "guix home reconfigure" (that builds and
>> ...
>
> Nice!
+1
> 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.
> ;-)
Home is used for too many things: configuration, personal data storage,
caching in hidden subdirectories, etc. It will take time to sort this
out, but I like the direction, including read-only for the configuration
stuff.
It's probably worth coordinating with other ideas for renovating home,
such as
https://www.phoronix.com/scan.php?page=news_item&px=systemd-homed
Different objectives, but also interesting ones, and it would be nice if
all that would end up being compatible.
Cheers,
Konrad.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-25 9:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-09-25 9:41 ` Konrad Hinsen
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).