all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: paul via Guix-patches via <guix-patches@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 68857@debbugs.gnu.org
Subject: [bug#68857] gnu: home: dotfiles: Avoid creating extra directory in $HOME.
Date: Tue, 20 Feb 2024 19:38:00 +0100	[thread overview]
Message-ID: <24f9f59a-79e8-27bc-5fe4-da160ed64187@autistici.org> (raw)
In-Reply-To: <87msrvmq7v.fsf_-_@gnu.org>

Hi Ludo’ ,

On 2/20/24 10:37, Ludovic Courtès wrote:
> Hello Giacomo!
>
> Giacomo Leidi <goodoldpaul@autistici.org> skribis:
>
>> The current implementation of the home-dotfiles-service-type contradicts
>> the Guix manual (see https://issues.guix.gnu.org/68848 ). This patch
>> properly implements both the plain and Stow dotfiles directory layouts.
>>
>> It does so by creating a new record type for each directory layout. This
>> approach, compared to having a single field in
>> home-dotfiles-configuration,
>> allows for having different layouts for different directories and to
>> carry additional information that might be required for some layouts.
>>
>> Implementing a new layout should just be a matter of creating a new
>> record type, defining a strip-*-dotfile procedure and plugging them into
>> the home-dotfiles-service-type.
>>
>> * gnu/home/services/dotfiles (home-dotfiles-stow-directory): New
>> variable;
>> (home-dotfiles-plain-directory): new variable;
>> (home-dotfiles-configuration): migrate to (gnu services configuration);
>> (strip-stow-dotfile): new variable;
>> (strip-plain-dotfile): new variable;
>> (home-dotfiles-configuration->files): use the new record types;
>> [directory-contents]: allow for
>> selecting a subset of application dotfile directories;
>> * doc/guix.texi: document the new layouts.
>>
>> Change-Id: I2e96037608353e360828290f055ec5271cfdfd48
> Thanks for working on it!
>
>> +There are two supported dotfiles directory layouts, for now. The
>> +@code{home-dotfiles-plain-directory} layout, which is structured as follows:
>> +
>> +@example
>> +~$ tree -a ./dotfiles/
>> +dotfiles/
>> +├── .gitconfig
>> +├── .gnupg
>> +│   ├── gpg-agent.conf
>> +│   └── gpg.conf
>> +├── .guile
>> +├── .config
>> +│   ├── guix
>> +│   │   └── channels.scm
>> +│   └── nixpkgs
>> +│       └── config.nix
>> +├── .nix-channels
>> +├── .tmux.conf
>> +└── .vimrc
>> +@end example
> I’d add a sentence like: “This tree structure is installed as is to the
> home directory upon @command{guix home reconfigure}.”
I'm adding this to the manual, thanks!
>> +(define-configuration/no-serialization home-dotfiles-configuration
> I think we should keep ‘home-dotfiles-configuration’ for compatibility
> (this patch keeps the exports but removes the actual
> <home-dotfiles-configuration> definition IIUC).
We are keeping home-dotfiles-configuration , it's just now it is 
implemented with validation from (gnu services configuration) . The only 
thing changing is that home-dotfiles-configuration's directories field 
is now a list of either home-dotfiles-plain-directory or 
home-dotfiles-stow-directory records.
> Also, as a rule of thumb, the configuration of a given service type is
> usually monomorphic (always the same configuration record type), which I
> find clearer.
>
> Instead of having these two record types, would it be an option to add a
> ‘type’ field (or similar) to <home-dotfiles-configuration>, as discussed
> earlier?

As I tried explaining in the commit message, this approach, compared to 
having a single field in home-dotfiles-configuration , allows for having 
different layouts for different directories and to carry additional 
information that might be needed for a given layout type. Such as the 
application field required to support some Stow's users workflows. What 
do you think about this approach? It should be general enough to support 
any kind of layout.

Thank you for your time,

giacomo





  reply	other threads:[~2024-02-20 18:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 22:15 [bug#68857] gnu: home: dotfiles: Avoid creating extra directory in $HOME paul via Guix-patches via
2024-01-31 22:17 ` [bug#68857] [PATCH] " Giacomo Leidi via Guix-patches via
2024-02-07  0:54 ` paul via Guix-patches via
2024-02-07  8:05   ` Janneke Nieuwenhuizen
2024-02-07  8:37     ` Janneke Nieuwenhuizen
2024-02-16 17:16   ` paul via Guix-patches via
2024-02-16 18:57     ` Sergey Trofimov
2024-02-16 17:17 ` [bug#68857] [PATCH v2] gnu: home: dotfiles: Properly support both plain and Stow directory layouts Giacomo Leidi via Guix-patches via
2024-02-20  9:37   ` [bug#68857] gnu: home: dotfiles: Avoid creating extra directory in $HOME Ludovic Courtès
2024-02-20 18:38     ` paul via Guix-patches via [this message]
2024-02-27 10:17       ` Ludovic Courtès
2024-02-27 11:30         ` Giacomo Leidi
2024-02-27 11:32         ` paul via Guix-patches via
2024-02-27 12:35 ` [bug#68857] [PATCH v3] gnu: home: dotfiles: Properly support both plain and Stow directory layouts Giacomo Leidi via Guix-patches via
2024-03-04 15:46   ` [bug#68857] gnu: home: dotfiles: Avoid creating extra directory in $HOME Ludovic Courtès
2024-03-06 20:51     ` paul via Guix-patches via
2024-03-06 20:52 ` [bug#68857] [PATCH v4] gnu: home: dotfiles: Properly support both plain and Stow directory layouts Giacomo Leidi via Guix-patches via
2024-03-06 22:15   ` bug#68848: bug#68857: gnu: home: dotfiles: Avoid creating extra directory in $HOME Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24f9f59a-79e8-27bc-5fe4-da160ed64187@autistici.org \
    --to=guix-patches@gnu.org \
    --cc=68857@debbugs.gnu.org \
    --cc=goodoldpaul@autistici.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.