Re: Early feedback on Guix Home

[Xinglu Chen <public@yoctocell.xyz>]

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

On Wed, Jun 23 2021, Ludovic Courtès wrote:

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

Yeah, the output is pretty verbose, which is good if someone is just
getting started with it, but there should probably also be an option to
make it less verbose.

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

Yeah, the manual needs some more work, maybe we should add an ‘migrating
to Guix Home’ section?

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

There is a ‘home-generic-service’ procedure that allows one to install
packages in dump a file somewhere in their home directory.

  (home-generic-service
   'ssh-config
   #:packages (list openssh)
   #:files `(("ssh/config"
              ,(local-file "/path/to/some/ssh/config"))))

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

As Andrew mentioned, I recently added a ‘guix home import’ command, but
in only imports the installed user packages.  Creating configurations
for the packages would require a lot more work, unless we just read the
contents of ~/.bashrc and ~/.config/git/config and use
‘home-generic-service’ and ‘plain-file’, instead of using
‘home-bash-configuration’ and ‘home-git-configuration’.

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

That would require a lot of work; we would have to parse all sorts of
weird configuration formats, not to mention that the upstream
configuration format can change in the future.  It would be nice to
have, but I don’t think it should be a blocker for merging Guix Home.

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

Since we already have the ‘home-generic-service’ helper, I am not sure
if explicitly providing an escape hatch for every single service is
worth it.  I feel like the point is to use Scheme to configure things,
and not to just concatenate big opaque strings.  People who haven’t
re-written their configs in Scheme can always use
‘home-generic-service’.  ‘home-generic-service’ is also useful if say
the user wants to configure Mpv, but there is no Mpv service in Guix
Home.

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

Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
extenal file, but using existing APIs like ‘local-file’ is probably a
better idea.

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

Thank you for the feedback!  Great to see that people are using and
enjoying Guix Home :)

> 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

Alternatively, one can also use it as a channel:

  (channel
    (name 'rde)
    (url "https://git.sr.ht/~abcdw/rde"))
    (introduction
     (make-channel-introduction
      "257cebd587b66e4d865b3537a9a88cccd7107c95"
      (openpgp-fingerprint
       "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0"))))

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