Early feedback on Guix Home

[Ludovic Courtès]

Hello!

As discussed on IRC a few days ago, I finally gave Guix Home a try and I
like it!

I thought I’d share my first impressions so we can try and address them
in the process of getting it merged.

First, I think one of the main reasons why it took me so long to try it
out is that I was afraid of what would happen at “activation time” (upon
reconfigure).  Were my dot files going to be deleted?  If so, which ones
exactly should I back up?  That led me to look more closely at the code
to better understand what was going to happen.  I found
‘symlink-manager.scm’, which is what I was looking for, but that code is
fairly complex.

Anyway, I backed up a bunch of files :-) and eventually gave it a try,
just to notice that ‘guix home reconfigure’ was very careful about
creating backups of any files it was going to overwrite, and it was also
explicitly saying what it’s doing.  Perfect.

I see two possible improvements:

  1. Make the manual very upfront about that: don’t be afraid, config
     files are backed up at that location, etc.

  2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
     easier to understand what’s going on.

Second, the other thing that stopped me from getting started is the
initial config.  How could I move from all my undisciplined dotfiles to
the single explicit config?  Eventually, I found that starting with
nothing but packages, ‘home-bash-service-type’, and
‘home-ssh-service-type’ was the most reasonable option to begin with.

Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
have a long ‘.ssh/config’ file and I wasn’t going to turn that into
‘ssh-host’ lines by hand.

Possible actions:

  1. Provide a ‘guix home init’ command (or similar) that creates an
     initial Home config based on existing config.

  2. In some cases, such as OpenSSH, provide converters from the native
     format to its Scheme equivalent (maybe?).

  3. For each service, provide an escape hatch: a way for users to
     provide a raw config file.  We do that for all or most of the Guix
     System services, and it helps a lot when people are starting from
     an existing config.

In terms of API, I noticed that in places such as
‘home-bash-configuration’, config snippets are represented as a list of
strings (internally passed to ‘mixed-text-file’).  That forces users to
mix different languages in their .scm file—e.g., half of my Home config
is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
inconvenient.

Possible action:

  1. Change config records to accept file-like objects instead of
     strings.  That way, users can choose to have snippets inlined (in a
     ‘plain-file’ object) or separate (via ‘local-file’).  See for
     example how ‘tor-configuration->torrc’ does it.

That’s it.  I hope it makes sense to you!

I encourage everyone to give it a spin, fearlessly!
What I did was (roughly):

  git clone https://git.sr.ht/~abcdw/rde
  guix git authenticate \
    "257cebd587b66e4d865b3537a9a88cccd7107c95" \
    "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
    -k origin/keyring
  ./pre-inst-env guix home reconfigure /path/to/home-config.scm

Thanks,
Ludo’.