Re: Early feedback on Guix Home

[Andrew Tropin]

Xinglu Chen <public@yoctocell.xyz> writes:

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

Yup, on my todo list.

>>   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 most cases we allows gexps or/and file-like objects (with
`local-file` and include/load or similar directive provided by target
software it's easy to include/source already existing file), so it's
almost always a way to take current plain-text file configuration and
include or slurp it into configuration home-service.  In other words,
there is already an escape hatch for almost every home-service.

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

`slurp-file-gexp` is a simple function, which returns a gexp, which
reads file from store and returns it's content (in most cases to be
added to mixed-text-file), it's expected that user will use it with
file-like object provided by local-file or any other way.  The final
configuration will look like:

`((key1 . value2)
  (key2 . (list of values))
  ,(slurp-file-gexp (local-file "./file/to/inline"))
  (key3 . value3))

It's done this way, because for many apps it's hard to provide a
separate field like in tor-configuration, because it's not clear where
this file should be added (at the end or at the beginning of the file or
inside special section).  To make a generic solution we do not provide a
separate field for file-like object, which contains "plain-text"
configuration, but allows to use one of two options above, which allows
to achieve the same, but provides more fleixbility and makes
configurations of home-services more consistent/uniform.

I'll try to write a guideline for defining home-services in the near
future and will try to explain all the patterns and best practices for
service configurations, after that will start adjusting currently
existing services to conform guideline (in case they do not yet).

>> 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"))))