Ludovic Courtès <[email protected]> writes: > Hi, > > Xinglu Chen <[email protected]> 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.
Will mention it in the manual. > 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. Acually, the idea behind `slurp-file-gexp` is that you always know where it will be inserted, because it will be inside the specific section of the configuration. Take a look at emacs home-service example: https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91 I'll explain it in more details in the manual. Correct me, if I missunderstood your point.
