Re: Early feedback on Guix Home

[Ludovic Courtès]

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

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

[...]

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

Yes.  Also, we’ll have to make sure it’s internationalized.

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

That’s a good idea.

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

Neat.

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

For SSH, generating something like:

   (service home-ssh-service-type
            (home-ssh-configuration
             (toplevel-options
              `((include . ,(local-file "ssh.conf"))))))

should be doable.  But yeah, we’ll have to see on a case-by-case basis
what can be achieved.

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

Agreed.

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

Yeah, ‘home-generic-service’ helps a lot, I didn’t know about it.

Overall, I think what I’m saying is that we should offer a smooth and
gradual transition for enthusiasts (like me!) who’re willing to switch
but can’t just be expected to rewrite all their config at once.

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

Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
code snippet), but as a user you don’t know where that snippet is going
to be inserted; it may not work in some contexts.

Thanks!

Ludo’.