unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Julien Lepiller <julien@lepiller.eu>
Cc: guix-devel@gnu.org
Subject: Re: Managing user environments
Date: Mon, 29 Jul 2019 18:04:33 +0200	[thread overview]
Message-ID: <87h8747rou.fsf@elephly.net> (raw)
In-Reply-To: <1D6F50BE-4430-4B1C-8F71-0AF1D6D84648@lepiller.eu>


Hi Julien,

> A few months ago, I created a new channel called the guix home manager
> whose purpose is to allow to manage user environments in a similar way
> to services.
>
> The channel is about managing dotfiles. I think configuration should
> be managed in a stateless fashion, and that's what guix is good at.

I think this is a very good idea and I’d love to see more integration
with Guix.

> You can find the current code here: https://framagit.org/tyreunom/guix-home-manager

I’m not convinced that a package definition is the most appropriate
abstraction to use here, because we only really care about the builder.
Using a profile is probably a good idea, though, because of roll-backs
etc.  Much like “guix pull” builds a profile under the hood, the home
manager could do the same.

Other ideas I mentioned on IRC were:

- integration with “guix system” and/or manifests; running “guix package
  --profile…” is probably not the most convenient interface.

- storage of secrets.  Can we (or: does it make sense to) encrypt the
  generated configuration files and use a PAM service to automatically
  unlock and relocate them upon login?

> I still have some doubts about it, whether it's in the scope for guix
> or not, whether it actually scales, and such. Any opinion is
> welcome. Again, would you like to see it, or a modified version of
> it,in guix itself or should it be kept in a separate channel?

I’d love to see a variant of this become part of Guix proper in the
future.  It shouldn’t be forced upon users, of course, but I think it
would be great to offer this as an opt-in feature, much like stricter
package management with manifests is opt-in.

Thank you for sharing this!

--
Ricardo

  reply	other threads:[~2019-07-29 16:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 15:13 Managing user environments Julien Lepiller
2019-07-29 16:04 ` Ricardo Wurmus [this message]
2019-07-30  8:46   ` Pierre Neidhardt
2019-07-30  9:32     ` Ricardo Wurmus

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=87h8747rou.fsf@elephly.net \
    --to=rekado@elephly.net \
    --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).