GNU bug report logs - #68857
gnu: home: dotfiles: Avoid creating extra directory in $HOME.

Previous Next

Full log

Message #44 received at 68857 <at> debbugs.gnu.org (full text, mbox):

From: Giacomo Leidi <leidigiacomo <at> outlook.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 68857 <at> debbugs.gnu.org
Subject: Re: [bug#68857] gnu: home: dotfiles: Avoid creating extra directory
 in $HOME.
Date: Tue, 27 Feb 2024 12:30:30 +0100

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

Hi Ludo' ,

First of all thank you for putting the time for working on this, I hope 
we are close to a solution :)

On 2/27/24 11:17, Ludovic Courtès wrote:
> I think we’ll only want to support two layouts: Stow and “plain”; we
> should avoid overengineering that.  That’s why a simple (layout 'stow)
> field seems good enough for me.
>
> WDYT?

I think it is important, if the effort is feasible, to not leave anyone 
behind (in terms of what the features of this service are) . Having a 
single field without further changes will introduce some ambiguity imo. 
We have these requirements in my understanding:

1. The service should support Stow's users workflows. This is a hard
   requirement in my opinion. Hence we need a way to select a subset
   the applications directories (the applications field of
   home-dotfiles-stow-directory in v2 of the patch).
2. The service should support Stow's users workflows. This is also a
   hard requirement. For this we just need the path of the dotfiles
   directory.
3. The service should support multiple dotfiles directories. This is
   not a hard requirement i believe, but we currently have this feature
   (the directories field of home-dotfiles-configuration is a list of
   strings not a string).

Introducing a single layout field makes it impossible to unambiguously 
implement requirement 1. If the user has more than directory it really 
makes no sense to select the same subset of applications for each one of 
them. This is to say that I believe it makes little sense to have 
multiple directories if the layout and applications information are not 
linked somehow with each directory. I wouldn't call this 
overengineering, just implementing the features users need from this 
service. I hope you agree.

Also since I first sent this service around Jan 2023 (when it was still 
the home-stow-migration-service), and it has been broken on master for 
some time I'd like to provide a fix for this situation as soon as 
possible (clearly the definition of brokennes and what changes to the 
API would be breaking user configs depends on the requirements one 
intends for the home-dotfiles-service-type, especially since the changes 
that broke master were introduced without consensus).

I'm changing the code to: use the layout field, support Stow's users 
workflow adding a new optional field called packages, which makes sense 
only if the layout is 'stow, and I'm making the directories field a 
string instead of a list of strings. Please let me know your thoughts on 
this v3.


Thank your for your work,


giacomo

[Message part 2 (text/html, inline)]

Previous Next

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