unofficial mirror of 
 help / color / mirror / code / Atom feed
From: Tissevert <>
Subject: Guix home and operating-system
Date: Wed, 6 Jul 2022 11:20:11 +0200	[thread overview]
Message-ID: <> (raw)

Hi Guix,

I'm finally having some time to try and put guix on the older machines at home
and thought I'd start by generating a live CD to show the rest of the family
what that would look like without having to make any irreversible changes yet.

Meanwhile, as this is a time to clean and rationalize system declarations to
ease maintaining the various machines, I thought it would be an appropriate
time to try and start learning about guix home (I came to guix for the
reproducibility, I'm not going to spend hours on each machine reproducing the
same user config !).

To my greatest astonishment, I found no way to make guix home configurations
interact with operating-system declarations. I expected something along the
lines of a "configuration" or "home" field in the user-account data type, which
could contain directly a valid guix home configuration or maybe the path to a
file containing one. At least, I expected to find a "packages" field to allow
specifying the packages set for a particular user. This is of course necessary
when building a read-only live image which won't be able to receive
modification at a later time. More generally, this raised a question in me: why
go to such length to have a whole declarative system which you can generate in
advance on each aspect, and then require to launch (stateful !) command lines
at a later time to alter the configuration of users.

I was discussing that the other night with @unmatched-paren on IRC and was told
this could be an interesting idea so what do you think ? Is there a good reason
why this hasn't been implemented ? Would it be very complicated to run the
equivalent of a guix home at the end of the system generation ? I'd be
personally interested to work on such a feature but I have absolutely no idea
where to start and would be glad to receive some pointers if it was deemed
useful enough that I should spend my time on it.

Now I can think of several ways to do that differently: I suppose the live CD
could have a system service performing the call to guix home to setup the
user's environment during the boot. Also, this would not cover user services
but regarding file configurations, I can think of a way because I'm prone to
config vertigo these days: there are so many levels where we can alter the
config, why always delay it ? Packages often contain a default configuration,
and upon start the program checks half a dozen places for a custom user config:
in other words why have a bash profile in my home when I could generate a bash
package which has directly my dream profile in its "default" version in /etc ?
I could still use ~/.bash_profile for a temporary tweak. Is that something
people in guix do frequently ? Why ?



             reply	other threads:[~2022-07-06 11:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06  9:20 Tissevert [this message]
2022-07-08  8:12 ` Guix home and operating-system Andrew Tropin
2022-07-18  9:38   ` Ludovic Courtès
2022-07-27  8:34     ` Andrew Tropin
2022-07-28  0:27       ` bokr
2022-07-28  9:26         ` david larsson

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:

  List information:

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

  git send-email \ \ \ \

* 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

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