GNU bug report logs - #60521
[PATCH] home: Add home-stow-migration-service.

Previous Next

Full log

View this message in rfc822 format

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Giacomo Leidi <goodoldpaul <at> autistici.org>, 60521 <at> debbugs.gnu.org
Subject: [bug#60521] [PATCH] home: Add home-stow-migration-service.
Date: Wed, 25 Jan 2023 10:32:29 +0400

[Message part 1 (text/plain, inline)]

On 2023-01-23 11:23, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin <andrew <at> trop.in> skribis:
>
>>>> +A suitable configuration would then be:
>>>> +
>>>> +@lisp
>>>> +  (home-stow-migration-service
>>>> +   (string-append (getenv "HOME")
>>>> +                  "/.dotfiles"))
>>>> +@end lisp
>>
>> The service looks neat!  Thank you, Giacomo.
>>
>> Ludo, wouldn't it be better and safer to use (local-file "./dotfiles"
>> #:recursive? #t) here?  I find it kinda dangerous for reproducibility to
>> reference local files and make logic inside the service to depend on it.
>
> Currently I don’t think that’s possible because the service imports
> those files at configuration time, but the end result is the same: those
> dot files are copied to the store and that’s what’s referenced.
>
> I think it’s okay like this, but I don’t have a strong opinion.
>
> That said, from a usability viewpoint, it does mean that users would
> typically have to version-controlled directories (one with the Home
> config file, and one with the Stow-style dot file tree), which is not
> great.  Perhaps the manual could say something about it.
>

The long-term idea I have is to provide a hermetic evaluation mode (not
only for home environments, but for guix in general), which allows to
make sure programmatically that all files referenced comes from either
origins with hash explicitly specified or commited in the current vcs
repository.  This way by changing things like

(local-file "./dotfiles" #:recursive? #t) to something like
(file-append (current-repo) "/dotfiles") or
(vcs-file "dotfiles" #:recursive? #t)

we will be able to guarantee that one didn't forget to copy all needed
dependencies for the configuration and to keep API "future compatible"
looks like a good idea.

Just thinking out loud, someday will make a separate
thread/note/prototype on this topic.  

Anyway, this service looks good enough to me with the current
implementation and seems potentially helpful.

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.