unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrew Tropin <andrew@trop.in>
To: Tissevert <tissevert+guix@marvid.fr>, guix-devel@gnu.org
Subject: Re: Guix home and operating-system
Date: Fri, 08 Jul 2022 11:12:02 +0300	[thread overview]
Message-ID: <87tu7s6n1p.fsf@trop.in> (raw)
In-Reply-To: <20220706112011.77c71a94@marvid.fr>


[-- Attachment #1.1: Type: text/plain, Size: 3604 bytes --]

On 2022-07-06 11:20, Tissevert wrote:

> 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 ?
>
> Cheers,
>
> Tissevert
>

Hi Alice!

This topic was discussed a few times already, but still not yet
implemented.  Probably the last one was "Guix system with
home-environment" in help-guix mailing list.

I played around with it, did some changes to Guix Home (maybe some small
patches not yet upstreamed, but they are not critical IIRC), but didn't
finish the implementation and postpone it again, still think it's really
valuable feature.

I don't remember all the details and where I stopped, but the highlevel
idea is following:

- Define a system services, which contains (user . home-environment) pairs.
- Build home environments on system reconfigure.
- Activate home environments on boot.

Here are some WIP half an year old code for guix-home-service-type:

[-- Attachment #1.2: home.scm --]
[-- Type: application/octet-stream, Size: 2075 bytes --]

(define-module (gnu services home)
  #:use-module (gnu services)
  #:use-module (gnu services shepherd)

  #:use-module (guix gexp)
  #:use-module (guix packages)
  #:use-module (guix records)

  #:export (guix-home-service-type))

(define (guix-home-activation-gexp config)
  #~(begin
      (map
       (lambda (x y)
         (let* ((user (getpw x))
                (uid (passwd:uid user))
                (gid (passwd:gid user))
                (dir (passwd:dir user)))
           (format #t "Running activation script for ~a,\n the path is ~a." x y)

           (mkdir-p dir)
           (chown dir uid gid)

           (setuid uid)
           (setenv "HOME" dir)
           ;; TODO: maybe not needed?
           ;; (setgid gid)
           (system y)))
       '#$(map car config)
       '#$(map (lambda (x) (file-append (cdr x) "/activate")) config))))

(define (guix-home-shepherd-service config)
  (map
   (lambda (x)
     (let ((user (car x))
           (he (cdr x)))
       (shepherd-service
        (documentation "Activate Guix Home.")
        (requirement '(user-homes))
        (provision (list (symbol-append 'guix-home- (string->symbol user))))
        (one-shot? #t)
        (auto-start? #f)
        (start #~(make-forkexec-constructor
                  '(#$(file-append he "/activate"))
                  #:user #$user
                  #:environment-variables
                  (list (string-append "HOME=" (passwd:dir (getpw #$user))))
                  #:group "users"))
        (stop #~(make-kill-destructor)))))
     config))

(define (guix-home-gc-roots config)
  (map cdr config))

(define guix-home-service-type
  (service-type
   (name 'guix-home)
   (description "Setups home-environments specified in the value.")
   (extensions (list (service-extension
                      shepherd-root-service-type
                      guix-home-shepherd-service)
                     (service-extension
                      gc-root-service-type
                      guix-home-gc-roots)))
   ;; (compose append)
   ;; (extend append)
   (default-value '())))

[-- Attachment #1.3: Type: text/plain, Size: 37 bytes --]


-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2022-07-08  8:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06  9:20 Guix home and operating-system Tissevert
2022-07-08  8:12 ` Andrew Tropin [this message]
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:
  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=87tu7s6n1p.fsf@trop.in \
    --to=andrew@trop.in \
    --cc=guix-devel@gnu.org \
    --cc=tissevert+guix@marvid.fr \
    /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).