[PATCH] home: Add home-stow-migration-service.

> * gnu/home/services.scm (dotfiles-for-app): New variable;

> (home-stow-migration-configuration): new variable;

> (home-stow-migration-service): new variable.

> * doc/guix.texi: Document it.

> @@ -41119,6 +41120,55 @@ to use alternative services to implement more advanced use cases like

> read-only home. Feel free to experiment and share your results.

> @end defvr

>

> +@deffn {Scheme Procedure} home-stow-migration-service

> +Return a service which is very similiar to @code{home-files-service-type}

> +(and actually extends it), but designed to ease the way into using Guix

> +Home for GNU Stow users. This service allows users to point Guix Home to

> +their Stow directory and have their file automatically deployed to their home

> +directory just like Stow would, without migrating all of their dotfiles to Guix

> +native configurations.

> +

> +A typical Stow setup consists of a source directory and a target directory.

> +The source directory must be structured as follows:

> +

> +@example

> +~$ tree -a .dotfiles/

> +.dotfiles/

> +??? git

> +? ??? .gitconfig

> +??? gpg

> +? ??? .gnupg

> +? ??? gpg-agent.conf

> +? ??? gpg.conf

> +??? guile

> +? ??? .guile

> +??? guix

> +? ??? .config

> +? ??? guix

> +? ??? channels.scm

> +? ??? .gitignore

> +??? nix

> +? ??? .config

> +? ? ??? nixpkgs

> +? ? ??? config.nix

> +? ??? .nix-channels

> +??? tmux

> +? ??? .tmux.conf

> +??? vim

> + ??? .vimrc

> +

> +13 directories, 10 files

> +@end example

> +

> +A suitable configuration would then be:

> +

> +@lisp

> + (home-stow-migration-service

> + (string-append (getenv "HOME")

> + "/.dotfiles"))

> +@end lisp

> +(define (dotfiles-for-app app-dir)

> + "Return a list of objects compatible with @{home-files-service-type}'s

> +value. Each object is a pair where the first element is the relative path

> +of a file and the second is a gexp representing the file content. Objects are

> +generated by recursively visiting APP-DIR and mapping its contents to the

> +user's home directory."

> + (let ((app-absolute-path (canonicalize-path app-dir)))

> + (map (lambda (path)

> + (let ((app-file-relative-path

> + (string-replace-substring path

> + (string-append app-absolute-path "/")

> + "")))

> + (list app-file-relative-path

> + (local-file path

> + (string-append "home-stow-migration-"

> + (string-replace-substring

> + app-file-relative-path

> + "/" "-"))))))

> + (find-files app-absolute-path))))

> +(define (home-stow-migration-configuration stow-dir)

> + "Return a list of objects compatible with @{home-files-service-type}'s

> +value, generated following GNU Stow's algorithm using STOW-DIR as input

> +directory."

> + (define (dir-contents dir)

> + (scandir dir

> + (lambda (name)

> + (not (member name '("." ".."))))))

> + (fold append

> + '()

> + (map (lambda (app-dir)

> + (dotfiles-for-app

> + (string-append stow-dir "/" app-dir)))

> + (dir-contents stow-dir))))

> +(define-public (home-stow-migration-service stow-dir)

> Hi!

>

> Giacomo Leidi <goodoldpaul@autistici.org> skribis:

>

>> * gnu/home/services.scm (dotfiles-for-app): New variable;

>> (home-stow-migration-configuration): new variable;

>> (home-stow-migration-service): new variable.

>> * doc/guix.texi: Document it.

>

> That looks very useful!

>

>> @@ -41119,6 +41120,55 @@ to use alternative services to implement more advanced use cases like

>> read-only home. Feel free to experiment and share your results.

>> @end defvr

>>

>> +@deffn {Scheme Procedure} home-stow-migration-service

>

> Perhaps write a short intro (one or two sentences) above?

>

>> +Return a service which is very similiar to @code{home-files-service-type}

>> +(and actually extends it), but designed to ease the way into using Guix

>> +Home for GNU Stow users. This service allows users to point Guix Home to

>> +their Stow directory and have their file automatically deployed to their home

>> +directory just like Stow would, without migrating all of their dotfiles to Guix

>> +native configurations.

>> +

>> +A typical Stow setup consists of a source directory and a target directory.

>> +The source directory must be structured as follows:

>> +

>> +@example

>> +~$ tree -a .dotfiles/

>> +.dotfiles/

>> +??? git

>> +? ??? .gitconfig

>> +??? gpg

>> +? ??? .gnupg

>> +? ??? gpg-agent.conf

>> +? ??? gpg.conf

>> +??? guile

>> +? ??? .guile

>> +??? guix

>> +? ??? .config

>> +? ??? guix

>> +? ??? channels.scm

>> +? ??? .gitignore

>> +??? nix

>> +? ??? .config

>> +? ? ??? nixpkgs

>> +? ? ??? config.nix

>> +? ??? .nix-channels

>> +??? tmux

>> +? ??? .tmux.conf

>> +??? vim

>> + ??? .vimrc

>> +

>> +13 directories, 10 files

>> +@end example

>> +

>> +A suitable configuration would then be:

>> +

>> +@lisp

>> + (home-stow-migration-service

>> + (string-append (getenv "HOME")

>> + "/.dotfiles"))

>> +@end lisp

>

> Maybe add a description of what it’s going to do with those files? It’s

> kinda implicit but better be clear.

>

> Also, I feel like there’s nothing really Stow-specific here; it just

> happens to be a file layout convention that’s used by Stow, right? So I

> wonder if could frame it differently, by describing the expected file

> tree structure first, and mentioning Stow only then?

>

> Last, I suggest adding a cross-reference to the Stow manual, as in:

>

> @pxref{Top,,, stow, GNU Stow Manual}

>

>> +(define (dotfiles-for-app app-dir)

>> + "Return a list of objects compatible with @{home-files-service-type}'s

> ^

> Typo, should be @code.

>

>> +value. Each object is a pair where the first element is the relative path

>> +of a file and the second is a gexp representing the file content. Objects are

>> +generated by recursively visiting APP-DIR and mapping its contents to the

>> +user's home directory."

>> + (let ((app-absolute-path (canonicalize-path app-dir)))

>> + (map (lambda (path)

>> + (let ((app-file-relative-path

>> + (string-replace-substring path

>> + (string-append app-absolute-path "/")

>> + "")))

>

> Or just (string-drop path (string-length app-absolute-path)).

>

>> + (list app-file-relative-path

>> + (local-file path

>> + (string-append "home-stow-migration-"

>> + (string-replace-substring

>> + app-file-relative-path

>> + "/" "-"))))))

>> + (find-files app-absolute-path))))

>

> Nitpick: by convention, the term “path” refers to “search paths”; here

> we’d instead use “file name”, but you can also call the variable just

> ‘file’.

>

> The other convention is to avoid abbreviations in identifiers, and to

> avoid long identifiers for local variables.

>

> So s/app-dir/directory/ etc.

>

>> +(define (home-stow-migration-configuration stow-dir)

>> + "Return a list of objects compatible with @{home-files-service-type}'s

>> +value, generated following GNU Stow's algorithm using STOW-DIR as input

>> +directory."

>> + (define (dir-contents dir)

>> + (scandir dir

>> + (lambda (name)

>> + (not (member name '("." ".."))))))

>> + (fold append

>> + '()

>> + (map (lambda (app-dir)

>> + (dotfiles-for-app

>> + (string-append stow-dir "/" app-dir)))

>> + (dir-contents stow-dir))))

>

> You can replace (fold append …) with (append-map …).

>

>> +(define-public (home-stow-migration-service stow-dir)

>

> You can drop this procedure. Users are expected to write:

>

> (service home-stow-migration-service)

>

> Could you send an updated patch?

>

> Thanks!

>

> Ludo’.

>

>

>

> * gnu/home/services.scm (dotfiles-for-app): New variable;

> (home-stow-migration-configuration): new variable;

> (home-stow-migration-service): new variable.

> * doc/guix.texi: Document it.

> ---

> doc/guix.texi | 50 +++++++++++++++++++++++++++++++++++++++++++

> gnu/home/services.scm | 49 ++++++++++++++++++++++++++++++++++++++++++

> 2 files changed, 99 insertions(+)

>

> diff --git a/doc/guix.texi b/doc/guix.texi

> index 5c85680831..40c36f65c4 100644

> --- a/doc/guix.texi

> +++ b/doc/guix.texi

> @@ -109,6 +109,7 @@ Copyright @copyright{} 2022 Reily Siegel@*

> Copyright @copyright{} 2022 Simon Streit@*

> Copyright @copyright{} 2022 (@*

> Copyright @copyright{} 2022 John Kehayias@*

> +Copyright @copyright{} 2023 Giacomo Leidi@*

>

> Permission is granted to copy, distribute and/or modify this document

> under the terms of the GNU Free Documentation License, Version 1.3 or

> @@ -41119,6 +41120,55 @@ to use alternative services to implement more advanced use cases like

> read-only home. Feel free to experiment and share your results.

> @end defvr

>

> +@deffn {Scheme Procedure} home-stow-migration-service

> +Return a service which is very similiar to @code{home-files-service-type}

> +(and actually extends it), but designed to ease the way into using Guix

> +Home for GNU Stow users. This service allows users to point Guix Home to

> +their Stow directory and have their file automatically deployed to their home

> +directory just like Stow would, without migrating all of their dotfiles to Guix

> +native configurations.

> +

> +A typical Stow setup consists of a source directory and a target directory.

> +The source directory must be structured as follows:

> +

> +@example

> +~$ tree -a .dotfiles/

> +.dotfiles/

> +??? git

> +? ??? .gitconfig

> +??? gpg

> +? ??? .gnupg

> +? ??? gpg-agent.conf

> +? ??? gpg.conf

> +??? guile

> +? ??? .guile

> +??? guix

> +? ??? .config

> +? ??? guix

> +? ??? channels.scm

> +? ??? .gitignore

> +??? nix

> +? ??? .config

> +? ? ??? nixpkgs

> +? ? ??? config.nix

> +? ??? .nix-channels

> +??? tmux

> +? ??? .tmux.conf

> +??? vim

> + ??? .vimrc

> +

> +13 directories, 10 files

> +@end example

> +

> +A suitable configuration would then be:

> +

> +@lisp

> + (home-stow-migration-service

> + (string-append (getenv "HOME")

> + "/.dotfiles"))

> +@end lisp

> +@end deffn

> +

> @defvr {Scheme Variable} home-xdg-configuration-files-service-type

> The service is very similiar to @code{home-files-service-type} (and

> actually extends it), but used for defining files, which will go to

> diff --git a/gnu/home/services.scm b/gnu/home/services.scm

> index 99035686f1..996647c592 100644

> --- a/gnu/home/services.scm

> +++ b/gnu/home/services.scm

> @@ -1,6 +1,7 @@

> ;;; GNU Guix --- Functional package management for GNU

> ;;; Copyright © 2021 Andrew Tropin <andrew@trop.in>

> ;;; Copyright © 2021 Xinglu Chen <public@yoctocell.xyz>

> +;;; Copyright © 2023 Giacomo Leidi <goodoldpaul@autistici.org>

> ;;;

> ;;; This file is part of GNU Guix.

> ;;;

> @@ -21,6 +22,7 @@ (define-module (gnu home services)

> #:use-module (gnu services)

> #:use-module ((gnu packages package-management) #:select (guix))

> #:use-module ((gnu packages base) #:select (coreutils))

> + #:use-module (guix build utils)

> #:use-module (guix channels)

> #:use-module (guix monads)

> #:use-module (guix store)

> @@ -33,13 +35,16 @@ (define-module (gnu home services)

> #:use-module (guix i18n)

> #:use-module (guix modules)

> #:use-module (srfi srfi-1)

> + #:use-module (ice-9 ftw)

> #:use-module (ice-9 match)

> + #:use-module (ice-9 string-fun)

> #:use-module (ice-9 vlist)

>

> #:export (home-service-type

> home-profile-service-type

> home-environment-variables-service-type

> home-files-service-type

> + home-stow-migration-service

> home-xdg-configuration-files-service-type

> home-xdg-data-files-service-type

> home-run-on-first-login-service-type

> @@ -49,6 +54,7 @@ (define-module (gnu home services)

>

> environment-variable-shell-definitions

> home-files-directory

> + home-stow-migration-configuration

> xdg-configuration-files-directory

> xdg-data-files-directory

>

> @@ -315,6 +321,49 @@ (define home-files-service-type

> (description "Files that will be put in

> @file{~~/.guix-home/files}, and further processed during activation.")))

>

> +(define (dotfiles-for-app app-dir)

> + "Return a list of objects compatible with @{home-files-service-type}'s

> +value. Each object is a pair where the first element is the relative path

> +of a file and the second is a gexp representing the file content. Objects are

> +generated by recursively visiting APP-DIR and mapping its contents to the

> +user's home directory."

> + (let ((app-absolute-path (canonicalize-path app-dir)))

> + (map (lambda (path)

> + (let ((app-file-relative-path

> + (string-replace-substring path

> + (string-append app-absolute-path "/")

> + "")))

> + (list app-file-relative-path

> + (local-file path

> + (string-append "home-stow-migration-"

> + (string-replace-substring

> + app-file-relative-path

> + "/" "-"))))))

> + (find-files app-absolute-path))))

> +

> +(define (home-stow-migration-configuration stow-dir)

> + "Return a list of objects compatible with @{home-files-service-type}'s

> +value, generated following GNU Stow's algorithm using STOW-DIR as input

> +directory."

> + (define (dir-contents dir)

> + (scandir dir

> + (lambda (name)

> + (not (member name '("." ".."))))))

> + (fold append

> + '()

> + (map (lambda (app-dir)

> + (dotfiles-for-app

> + (string-append stow-dir "/" app-dir)))

> + (dir-contents stow-dir))))

> +

> +(define-public (home-stow-migration-service stow-dir)

> + "Return a service extending @{home-files-service-type} with files from

> +STOW-DIR. Files will be put in the user's home directory following GNU

> +Stow's algorithm, and further processed during activation."

> + (simple-service 'home-stow-migration-service

> + home-files-service-type

> + (home-stow-migration-configuration stow-dir)))

> +

> (define xdg-configuration-files-directory ".config")

>

> (define (xdg-configuration-files files)

>

> base-commit: 473692b812b4ab4267d9bddad0fb27787d2112ff

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

> Hi,

>

> Andrew Tropin <andrew@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.

>

> * gnu/home/services.scm (dotfiles-for-app): New variable;

> (home-dotfiles-configuration): new variable;

> (home-dotfiles-service-type): new variable.

> * doc/guix.texi: Document it.

> +The @code{home-dotfiles-service-type} is designed to ease the way into using

> +Guix Home for this kind of users, allowing them to point the service to their

> +dotfiles directory (which must follow

> +@uref{https://www.gnu.org/software/stow/, GNU Stow}'s layout) and have their

> +For a more formal specification please refer to the

> +@pxref{Top,,, stow, GNU Stow Manual}.

> +@lisp

> + (simple-service 'home-dotfiles

> + home-dotfiles-service-type

> + (list (string-append (getcwd)

> + "/.dotfiles")))

> +(define (dotfiles-for-app directory)

> + "Return a list of objects compatible with @code{home-files-service-type}'s

> +value. Each object is a pair where the first element is the relative path

> +of a file and the second is a gexp representing the file content. Objects are

> +generated by recursively visiting DIRECTORY and mapping its contents to the

> +user's home directory."

> + (map (lambda (file)

> + (let ((file-relative-path

> + (string-drop file (1+ (string-length directory)))))

> + (list file-relative-path

> + (local-file file

> + (string-append "home-dotfiles-"

> + (string-replace-substring

> + file-relative-path

> + "/" "-"))))))

> + (find-files directory)))

> +(define-public (home-dotfiles-configuration dotfiles-directories)

> + "Return a list of objects compatible with @code{home-files-service-type}'s

> +value, generated following GNU Stow's algorithm for each of the

> +DOTFILES-DIRECTORIES."

> + (define (directory-contents directories)

> + (append-map

> + (lambda (directory)

> + (map

> + (lambda (content)

> + (with-directory-excursion directory

> + (canonicalize-path content)))

> + (scandir directory

> + (lambda (name)

> + (not (member name '("." "..")))))))

> + directories))

> + (append-map

> + dotfiles-for-app

> + (directory-contents dotfiles-directories)))

> It is possible to use it together with home-dotfiles- service-type.

>

>

>can you give a simple example? thanks

>

>

>

>

>

>

>--

>?????????????

>

>

>

>? 2024-01-22 01:06:19?paul <goodoldpaul@autistici.org> ???

>

>

>Hello Feng Shu,

>

>Apologies for the delay. I fixed the bug you pointed out for symlinks and spaces in file names. Thank you for catching them!

>

>About templating I would suggest you to use mixed-text-file or computed file from (guix gexp) and pass them directly to them home-files-service-type. It is possible to use it together with home-dotfiles-service-type.

>

>

>

>

>

>

>

>

>giacomo

> Hello Feng Shu,

>

> Apologies for the delay. I fixed the bug you pointed out for symlinks and spaces in file names. Thank you for

> catching them!

>

> About templating I would suggest you to use mixed-text-file or computed file from (guix gexp) and pass them

> directly to them home-files-service-type. It is possible to use it together with home-dotfiles-service-type.

>

> giacomo

> Hello,

>

> the following works for me with the attached configuration.

>

> $ tree -a .

> .

> ??? guix-home-project

> ??? .dotfiles

> ? ??? rime

> ? ??? .config

> ? ? ??? ibus

> ? ??? .emacs.d

> ??? test-config.scm

>

> 7 directories, 1 file

> $ echo hello > guix-home-project/.dotfiles/rime/.config/ibus/rime

> $ cd guix-home-project/.dotfiles/rime/.emacs.d/ && ln -s ../.config/ibus/rime ./

> $ ls -al

> total 4

> drwxr-xr-x 1 paul users 8 Jan 22 17:37 ./

> drwxr-xr-x 1 paul users 30 Jan 22 17:31 ../

> lrwxrwxrwx 1 paul users 20 Jan 22 17:37 rime -> ../.config/ibus/rime

> $ cd ../.. && guix home container --share=`pwd`/..=$HOME test-config.scm

> WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'

> WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'

> Cleaning up symlinks from previous home at /gnu/store/hpnywydkrfygcl2qplxwgypqqwny16x5-home.

>

> Removing /home/paul/.profile... done

> Removing /home/paul/.emacs.d/rime... done

> Removed /home/paul/.emacs.d.

> Removing /home/paul/.config/fontconfig/fonts.conf... done

> Removed /home/paul/.config/fontconfig.

> Removing /home/paul/.config/ibus/rime... done

> Removed /home/paul/.config/ibus.

> Removed /home/paul/.config.

> Cleanup finished.

>

> Symlinking /home/paul/.profile -> /gnu/store/l27r8vj94ggr3na9pb1snizsmvh0zrxl-shell-profile... done

> Symlinking /home/paul/.emacs.d/rime -> /gnu/store/05v76y32j495v8dw6aaknp91k0371q34-home-dotfiles-.emacs.d-rime... done

> Symlinking /home/paul/.config/fontconfig/fonts.conf -> /gnu/store/sfj8h6zbacaz3y3gqzxqsbz3621nq4jv-fonts.conf... done

> Symlinking /home/paul/.config/ibus/rime -> /gnu/store/lfw0i01pmwzaia6f7lb9c4p84y357pbd-home-dotfiles-.config-ibus-rime... done

> done

> Finished updating symlinks.

>

> Comparing /gnu/store/hpnywydkrfygcl2qplxwgypqqwny16x5-home/profile/share/fonts and

> /gnu/store/hpnywydkrfygcl2qplxwgypqqwny16x5-home/profile/share/fonts... done (same)

> Evaluating on-change gexps.

>

> On-change gexps evaluation finished.

>

> warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script

> won't execute anything. You can check if xdg runtime directory exists,

> XDG_RUNTIME_DIR variable is set to appropriate value and manually execute the

> -bash-5.1$ cat .emacs.d/rimex-home/on-first-login'-bash-5.1$ cat .emacs.d/rime

> hello

> -bash-5.1$ ls -al .emacs.d/

> total 4

> drwxr-xr-x 1 paul users 8 Jan 22 16:42 .

> drwxr-xr-x 1 paul users 234 Jan 22 16:42 ..

> lrwxrwxrwx 1 paul users 71 Jan 22 16:42 rime -> /gnu/store/05v76y32j495v8dw6aaknp91k0371q34-home-dotfiles-.emacs.d-rime

> -bash-5.1$

>

> Hope this helps,

>

> giacomo

>

> Hello Feng Shu,

>

> Apologies for the delay. I fixed the bug you pointed out for symlinks and spaces in file names. Thank you for

> catching them!

>

> About templating I would suggest you to use mixed-text-file or computed file from (guix gexp) and pass them

> directly to them home-files-service-type. It is possible to use it together with home-dotfiles-service-type.

>

> giacomo

> At the moment, I use the below code, seem to work well:

> Hi,

>

> On 1/24/24 12:58, Feng Shu wrote:

>> At the moment, I use the below code, seem to work well:

>

> I understand it's possible but it's really more easy and consistent to

> use gexp, for longer files you can import them with local-file and

> process them inside computed-file for example with substitute* from

> (guix build utils) i believe.

>

> But I should have fixed the bug for symlinks for real this time :) I'm

> sending an updated patchset, please let me know if v6 works for your

> use case.

>

> giacomo

>

> Hi!

>

> Giacomo Leidi <goodoldpaul@autistici.org> skribis:

>

>> * gnu/home/services.scm (dotfiles-for-app): New variable;

>> (home-stow-migration-configuration): new variable;

>> (home-stow-migration-service): new variable.

>> * doc/guix.texi: Document it.

>

> That looks very useful!

>

> Hi!

>

> Giacomo Leidi <goodoldpaul@autistici.org> skribis:

>

>> * gnu/home/services.scm (dotfiles-for-app): New variable;

>> (home-stow-migration-configuration): new variable;

>> (home-stow-migration-service): new variable.

>> * doc/guix.texi: Document it.

>

> That looks very useful!

>

> * gnu/home/services.scm (dotfiles-for-app): New variable;

> (home-dotfiles-configuration): new variable;

> (home-dotfiles-service-type): new variable.

> * doc/guix.texi: Document it.

> * gnu/home/services.scm: New file;

> (dotfiles-for-app): new variable;

> (home-dotfiles-configuration): new variable;

> (home-dotfiles-service-type): new variable.

> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

> * po/guix/POTFILES.in: Add it.

> * doc/guix.texi: Document it.

>

> Change-Id: I6769169cfacefc3842faa5b31bee081c56c28743

> Co-authored-by: Ludovic Courtès <ludo@gnu.org>

> (define* (as-local-files dir #:optional (trim-prefix dir))

> (let ((absolute-dir (string-append (getcwd) "/" dir))

> (to-trim (string-append (getcwd) "/" trim-prefix "/")))

> (map (lambda (fn)

> (list

> (del-prefix to-trim fn)

> (local-file (canonicalize-path fn) (del-prefix "."

> (basename fn)) #:recursive? #t)))

> (find-files absolute-dir))))

> Sergey Trofimov <sarg@sarg.org.ru> skribis:

>

>> (define* (as-local-files dir #:optional (trim-prefix dir))

>> (let ((absolute-dir (string-append (getcwd) "/" dir))

>> (to-trim (string-append (getcwd) "/" trim-prefix "/")))

>> (map (lambda (fn)

>> (list

>> (del-prefix to-trim fn)

>> (local-file (canonicalize-path fn) (del-prefix "."

>> (basename fn)) #:recursive? #t)))

>> (find-files absolute-dir))))

>

> As you saw, I proposed a different solution: capturing

> (current-source-directory) in ‘home-dotfiles-configuration’ and

> using

> that to compute absolute file names (without ever calling

> ‘canonicalize-path’).

>

> Using ‘getcwd’ would be incorrect or at least surprising: it

> would

> resolve file names relative to the current directory instead of

> relative

> to the directory that contains the source file.

>

> Hi Ludo' and Sergey,

> I'm not sure my previous emails reached you since I sent them to

> the -done address of the bug. I'm pasting

>

> We either need to change the manual or the code, I don't have a

> clear preference . At this point I'm just happy this is in Guix

> but

> right now the manual matches Stow's usual directory layout. The

> code in this state contradicts the documentation and does not

> take

> into account the additional "git" directory given dotfiles

> directory that looks like this:

>

> tree -a dotfiles/

> dotfiles/

> ??? git

> ??? .gitconfig

>

> 2 directories, 1 file

>

> this is [0] the layout that is documented in the manual, that

> Stow suggests and that I'm trying to implement.

> If you have something else in mind could you please share your

> layout?

> Anyway, the reason I replied was that I am also a former Stow user and

> in my eyes we should've extended existing `home-files-service-type`

> instead of making a specialized new one.

> If you check `stow` manual

> (https://www.gnu.org/software/stow/manual/html_node/Invoking-Stow.html#Invoking-Stow),

> it should be invoked with the names of packages to be

> installed/removed. `home-dotfiles-service` doesn't have a parameter

> for the list of packages and assumes that everything in the specified

> directory should be installed, a limitation that prevents me to start

> using it. In my dotfiles I have optional packages which I install

> depending on OS or machine's purpose. Sure the service could be

> amended with the said parameter, but why adding a new service when a

> more generic one exists and is fitting the use case?

> Hi Sergey ,

>

> Whether the stow manual mandates/suggests a given layout was

> analyzed here [0].

>

> The workflow you describe is not the only one possible and the

> app list is not mandatory. Only when -d is used, please look at

> my

> e-mail.

>

> Anyway, if the current implementation works with your directory

> layout could you please share your home-dotfiles-configuration?

>

>Hi,

>

>When I follow the documentation, and have

>

> dotfiles/guix/.config/guix/channels.scm

>

>that shows suing tree -a ./dotfiles

>

> dotfiles

> ??? guix

> ??? .config

> ??? guix

> ??? channels.scm

>

>similar to the documentaion, and using

>

> (service home-dotfiles-service-type

> (home-dotfiles-configuration

> (directories (list "./dotfiles"))))

>

>creates

>

> ~/guix/.config/guix/channels.scm

>

>an extra toplevel `guix" directory!

>

>What gives?

>

>Greetings,

>Janneke

>

>--

>Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org

>Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

> The code that was reverted was an intentional fix I introduced after trying the latest revision and having my home break :) . I just believe we are not aligned on the requirements. Ludo': does a tree -a call to your dotfiles directory resemble what is documented in the manual?

>

> We either need to change the manual or the code, I don't have a clear preference . At this point I'm just happy this is in Guix but right now the manual matches Stow's usual directory layout. The code in this state contradicts the documentation and does not take into account the additional "git" directory given dotfiles directory that looks like this:

>

> tree -a dotfiles/

> dotfiles/

> ??? git

> ??? .gitconfig

>

> 2 directories, 1 file

>

> Hi Ludo',

>

> On 2/7/24 23:17, Ludovic Courtès wrote:

>> Hi!

>>

>> Oops, my sincere apologies if I ended up “fixing” something that was in

>> fact intentional, effectively breaking it.

> Don't worry I think there's been a misunderstanding from the beginning

> and I was not able to explain myself . Sh*t happens :)

>> Should we just adjust the manual to match

>> this?

> I think that doing so would defeat the original purpose of supporting

> the de facto standard used by Stow users

>> Or the other way around, at the cost of breaking user config?

> This is really about what one means by breaking, we already received a

> bug report at https://issues.guix.gnu.org/68848 which in my opinion

> indicates that we give some expectations through the manual, which is

> not met by the code (I'm adding Janneke to this thread so that we are

> all aligned and can reach consensus).

>> Or adding an option to choose between these two layouts?

> This is the best option forward, in my opinion. It is flexible and

> allows for a both for the current simplified layout (without the

> per-application layer of directories typical of Stow) and the Stow

> default one.

>

> If there's consensus my next steps would be:

>

> 1. Apply Janneke's stylistic suggestion at

> https://issues.guix.gnu.org/68857 allowing us to close

> https://issues.guix.gnu.org/68848 and align the code with the manual

>

> 2. Add a layout field to home-dotfiles-configuration that allows for

> the simplified layout described by Ludo' in his last email, something

> like this

>

> $ guix shell tree -- tree -a dot-files/

> dot-files/

> ??? .dico

> ??? .gitconfig

> ??? .gnupg

> ?   ??? dirmngr.conf

> ?   ??? gpa.conf

> ?   ??? gpg.conf

> ?   ??? .gpg-v21-migrated

> ??? .Xdefaults

> ??? .xsession

>

> the default would be the current layout but this would allow for more

> flexibility in layouts in the future.

>

> 3. Possibly add an included-applications (the name is just a proposal)

> to support Sergey's use case of selecting a subset of application

> dotfiles to provision in the user's home

>

> what do you think about this plan?

>

> thank you all for your help and your time

>

> giacomo

>

> Hi!

>

> Oops, my sincere apologies if I ended up “fixing” something that was in

> fact intentional, effectively breaking it.

> Should we just adjust the manual to match

> this?

> Or the other way around, at the cost of breaking user config?

> Or adding an option to choose between these two layouts?

> On 2/7/24 23:17, Ludovic Courtès wrote:

>> Hi!

>>

>> Oops, my sincere apologies if I ended up “fixing” something that was in

>> fact intentional, effectively breaking it.

> Don't worry I think there's been a misunderstanding from the beginning

> and I was not able to explain myself . Sh*t happens :)

>> Should we just adjust the manual to match

>> this?

> I think that doing so would defeat the original purpose of supporting

> the de facto standard used by Stow users

>> Or the other way around, at the cost of breaking user config?

> This is really about what one means by breaking, we already received a

> bug report at https://issues.guix.gnu.org/68848 which in my opinion

> indicates that we give some expectations through the manual, which is

> not met by the code (I'm adding Janneke to this thread so that we are

> all aligned and can reach consensus).

>> Or adding an option to choose between these two layouts?

> This is the best option forward, in my opinion. It is flexible and

> allows for a both for the current simplified layout (without the

> per-application layer of directories typical of Stow) and the Stow

> default one.

>

> If there's consensus my next steps would be:

>

> 1. Apply Janneke's stylistic suggestion at

> https://issues.guix.gnu.org/68857 allowing us to close

> https://issues.guix.gnu.org/68848 and align the code with the manual

>

> 2. Add a layout field to home-dotfiles-configuration that allows for

> the simplified layout described by Ludo' in his last email, something

> like this

>

> $ guix shell tree -- tree -a dot-files/

> dot-files/

> ??? .dico

> ??? .gitconfig

> ??? .gnupg

> ?   ??? dirmngr.conf

> ?   ??? gpa.conf

> ?   ??? gpg.conf

> ?   ??? .gpg-v21-migrated

> ??? .Xdefaults

> ??? .xsession

>

> the default would be the current layout but this would allow for more

> flexibility in layouts in the future.

> 3. Possibly add an included-applications (the name is just a proposal)

> to support Sergey's use case of selecting a subset of application

> dotfiles to provision in the user's home

> paul <goodoldpaul@autistici.org> skribis:

>

>> On 2/7/24 23:17, Ludovic Courtès wrote:

>>> Hi!

>>>

>>> Oops, my sincere apologies if I ended up “fixing” something that was in

>>> fact intentional, effectively breaking it.

>> $ guix shell tree -- tree -a dot-files/

>> dot-files/

>> ??? .dico

>> ??? .gitconfig

>> ??? .gnupg

>> ?   ??? dirmngr.conf

>> ?   ??? gpa.conf

>> ?   ??? gpg.conf

>> ?   ??? .gpg-v21-migrated

>> ??? .Xdefaults

>> ??? .xsession

>>

>> the default would be the current layout but this would allow for more

>> flexibility in layouts in the future.

>

> Thinking about it, either we add a ‘layout’ field (the default should

> probably be the same as it is now, to user’s config will still work the

> same).