Re: Feature suggestion: .stow-rename

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.

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.

> - 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/applic=
ations
>
> 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.=C2=A0(I believe the specification is
still called XDG, although the organisation behind it is
freedesktop.org=C2=A0- probably since "XDG" is hardcoded into the names of
the environment variables.)

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.

> 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!