Re: [Stow-devel] Feature suggestion: .stow-rename

[Danielle McLean]

On 10/10/16 08:36, Danielle McLean wrote:
> I suggest an extension to Stow: the .stow-rename file. A file called
.stow-rename may be placed in the root directory of each package - it is
a text file in the format:
>
> stow_name => target_name
> stow_name_2 => target_name_2
>
> (This format was chosen as it closely resembles a Perl hash - which is
also what's used to store the rename information in my implementation. c: )

Hi again! It's been over a year since I last spoke about this feature.
Sorry about that! Anyway, since my last message I've implemented support
for reading and obeying .stow-rename files in upstream Stow - renames
are permitted to use arbitrary Perl pattern/substitute strings, so only
one rename definition is needed to reimplement the behaviour of
--dotfiles. Indeed, I changed the existing --dotfiles implementation so
it simply inserts the appropriate rename on the fly, and all the tests
for --dotfiles still pass. I'm pretty happy with it overall!

However, I'm not comfortable making a pull request yet, because I've
found a really tricky issue: attempting to unfold a directory will fail
if that directory has been renamed, by either --dotfiles or my new
.stow-rename implementation. Here's a simple example, tested using Stow
master.

$ mkdir -p ~/stowdir/first/dot-a/b ~/stowdir/second/dot-a/a

$ tree ~/stowdir -F
~/stowdir
├── first/
│   └── dot-a/
│       └── b/
└── second/
    └── dot-a/
        └── a/

$ stow --dotfiles -vvv -d ~/stowdir -S first second
stow dir is /Users/dani/stowdir
stow dir path relative to target /Users/dani is stowdir
cwd now /Users/dani
cwd restored to /Users/dani/builds/stow
cwd now /Users/dani
Planning stow of package first...
Stowing contents of stowdir/first (cwd=/Users/dani)
Stowing stowdir / first / .a
LINK: .a => stowdir/first/dot-a
Planning stow of package first... done
Planning stow of package second...
Stowing contents of stowdir/second (cwd=/Users/dani)
Stowing stowdir / second / .a
--- Unfolding .a which was already owned by first
UNLINK: .a (reverts previous action)
MKDIR: .a
Stowing contents of stowdir/first/.a (cwd=/Users/dani)
stow: ERROR: stow_contents() called with non-directory path:
stowdir/first/.a

Stowing exactly one of those two packages works, since it doesn't try to
unfold the target directory. Unfortunately, attempting to subsequently
stow the second package of course leads to unfolding and produces the
same error. Since the majority of my dotfiles packages keep stuff in
$XDG_CONFIG_HOME and therefore absolutely require unfolding to work,
this is a serious inconvenience.

I'm not really sure how to fix this - Stow seems to juggle the source
and target paths fairly readily, presumably under the assumption that
they're identical, so keeping them reliably separate seems tricky. The
version of Stow I wrote back in 2016 https://github.com/00dani/dot-stow
*does* handle this case properly, but it only supports static
replacements rather than patterns and wasn't written with contributing
upstream in mind, so I have no idea how it works now. :/

I've attached the diff for my new .stow-rename implementation, in case
there's something obviously wrong I haven't spotted, but since
--dotfiles has the same issue I kind of doubt it'll be simple.

Thoughts?
Danielle c:

stow-rename.patch
Description: Text document

signature.asc
Description: OpenPGP digital signature