Re: Feature suggestion: .stow-rename

On 11 October 2016 at 02:45, Danielle McLean <[email protected]> wrote:
> On 10 October 2016 at 21:53:45, Adam Spiers ([email protected]) wrote:
>> > Typically it is significantly preferable for your package contents to
>> > be visible
>>
>> Funnily enough, this never really bothered me personally, but I can
>> certainly appreciate that it might annoy others. That's why I merged
>> this nice new --dotfiles feature only 5 days ago :-)
>>
>> https://github.com/aspiers/stow/pull/17
>
> Hehe yes, I noticed --dotfiles in the mailing list archive shortly
> after sending my email. To be honest, I probably wouldn't have
> bothered to code my own version if I'd seen that feature. ;)

:-)

> There are a few important differences between --dotfiles and
> .stow-rename though:
>
>> - When focusing specifically on the dotfiles case, where the goal is
>> to "unhide" the files by removing the dot, I think that the existing
>> --dotfiles implementation is nicer because it requires less work of
>> the user. I don't like that the user would have to add a new entry
>> to .stow-rename every time they add a new file - this doesn't sound
>> user-friendly to me. However, if more flexibility is required in
>> the way that the unhidden files are named, I'm all ears for input
>> what kind of flexibility is required and how we could implement
>> that.
>
> The reason I designed .stow-rename as a file within individual
> packages is that it makes a package functionally standalone - you can
> safely `stow vim` without needing to check whether a --dotfiles flag
> is needed, and you can readily mix packages that use renames with
> packages that don't, even in a single call to Stow. As a package
> "consumer" rather than a package "creator", less work is required.

That's a very good point!

> Of course, I also made it more flexible than simply "add dots to the
> symlink names", mostly because I didn't anticipate that you'd already
> be considering dotfiles a primary use case for Stow. :) Having
> --dotfiles enabled by the presence of an empty "marker" file, like
> packagename/.stow-dotfiles, would probably be good enough in terms of
> making packages standalone.

Right.

>> - Regarding the use case of mapping paths for other reasons such as
>> following freedesktop.org (formerly known as XDG[0]) path
>> conventions, so far I have personally been mirroring the path
>> hierarchies in my own repositories, e.g.
>>
>> https://github.com/aspiers/desktop-config/tree/master/.local/share/applications
>>
>> so that when I stow this repository, stuff goes straight into my
>> ~/.local/share/applications. This works fine.
>
> I've taken this approach as well. The problem with designing your
> packages that way, I think, is that it's not *really* following the
> XDG base directory specification, because it only works for the
> default settings of the $XDG_* paths. (I believe the specification is
> still called XDG, although the organisation behind it is
> freedesktop.org - probably since "XDG" is hardcoded into the names of
> the environment variables.)

Yes, I think you're right.

> Although I seriously doubt anyone actually sets XDG_CONFIG_HOME to
> anything other than ~/.config, it is technically correct (the best
> kind of correct) to do so. As a result, a package that assumes
> package/.config will always go to the right place is technically
> incorrect. A package with a .stow-rename or similar file that
> redirects itself to $XDG_CONFIG_HOME would continue to work regardless
> of where $XDG_CONFIG_HOME actually is.

Right again :-)

>> Stow's value is in its simplicity, much of which comes from this
>> core principle of a 1-to-1 mapping between sub-paths in the package
>> directories and sub-paths in the target directory (modulo
>> folding).
>
> I completely agree that the simplicity of the design is a huge draw of
> Stow over alternatives - I tried half a dozen "dotfiles management"
> scripts before figuring out that using a symlink farm manager like
> Stow is far more straightforward.
>
> However, I don't believe .stow-rename support is really a huge
> departure from symlink farming - all it does is let you choose the
> names of the symlinks, after all - and to me it doesn't at all imply
> the need for further package manager features like dependency
> management. Additionally, one-to-one mapping of paths is already
> violated if --dotfiles is supported, since it does precisely the same
> thing in a fixed way!

... and again.  Which proves I was right to stay open-minded ;-)

So it seems clear that we could do better than the existing --dotfiles
implementation.  So, pull requests very welcome.  Although I would
prefer an implementation which caters for the most common use case
(i.e. dot files) by automatically doing the same kind of s/^\./dot-/
rename which --dotfiles does, without requiring an entry in
.stow-rename for each file.  Another possible approach would be to
allow a .stowrc in each Stow package, in which case usage would be
as simple as:

  echo --dotfiles > $STOW_DIR/$PACKAGE/.stowrc