Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès <ludo@gnu.org> writes:

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

Good to know, added a todo to make it clearer in the documentation.

> I found ‘symlink-manager.scm’, which is what I was looking for, but
> that code is fairly complex.

Yep, perhaps it a little monstous)  Maybe cleaning it up is a good idea
before sending the patch to guix.

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

Sounds reasonable)

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

Xinglu implemented `guix home import`, which creates a simple
home-environment configuration, which contains the same packages as 
~/.guix-profile

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

It's a good idea and Xinglu also mentioned it, but I find it to be a lot
of extra work, so I propose to postpone it until next time, IMO it's
better to focus on moving Guix Home from rde repo first in the current
state and add new functionality after that step is done, otherwise we
can stuck with wip-guix-home for months.

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

We do it as well, the only difference is that we try to utilize target
program capabilities or slurp-file-gexp helper for that.

The first one means that target configuration format allows to use some
directive to load the content of another file:
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/ssh.scm#L190
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L200

The second one inlines the content of file directly in configuration.
In most cases it's done by providing a gexp, which reads the content of
the file in the store and returning its content as a string to make
mixed-text-file to add it to the target configuration.
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L208

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

Can you elaborate on that please, ideally with some examples.

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

Make a lot of sense, thank you for the feedback and suggestions!)

> 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

And to get the initial configuration, it's a good idea to take a look at
gnu/home/examples directory or call import action:

   ./pre-inst-env guix home import > /path/to/home-config.scm

>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm

For people, who is not yet familiar with Guix Home, the project and
documentation web pages:

https://sr.ht/~abcdw/rde/
https://guix-home.trop.in/Home-Configuration.html#Home-Configuration