Managing user environments

Managing user environments

[Julien Lepiller]

Hi Guix!

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. Ricardo encouraged me today to thare it and maybe work on integrating it in Guix proper. What do you think?

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

This channel currently works by building a guix profile, so it provides roll-back and atomicity in general. The profile corresponds to the whole home directory, which makes it read-only. There are ways to "punch holes", especially for the XDG cache and data directories, but also for any unsupported application. Supported applications are configured with a record-type, like system services.

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?

Thanks!

Re: Managing user environments

[Ricardo Wurmus]

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

Re: Managing user environments

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

This looks fantastic!

I can see quite some overlap with Shepherd User Services:
https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html

What do you think?

If we implement shepherd user services, we would essentially be able to
declare most (all?) of a user home folder.

The main difference I can see with Julien's approach is that the
declarativeness is not enforced since home would not be read-only.
Home would be initialized declaratively, but then the user or any
program is able to overwrite files in home.  Which may or may not be the
desired behaviour.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Managing user environments

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> I can see quite some overlap with Shepherd User Services:
> https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html
>
> What do you think?

Yes, I felt reminded of Shepherd User Services as well.

> The main difference I can see with Julien's approach is that the
> declarativeness is not enforced since home would not be read-only.

This could still be done as part of the service actions if desired.

--
Ricardo