Full support for alternate directories (not just directories with a top-level tracked file)

[ian-h-chamberlain]

Is your feature request related to a problem? Please describe.

I use ##os.Darwin alts pretty frequently to avoid polluting my home directory on non-macOS systems. In particular, I have a number of files in ~/.config/yadm/alt/Library which are macOS-specific to avoid creating a ~/Library that would otherwise not exist on Linux.

Because alternate directory names only work if there is a file at the top level, I can't just create ~/.config/yadm/alt/Library##os.Darwin, since most files are in a subdirectory of Library, for example:

~/.config/yadm/alt/Library/
└── Application Support/
    └── Code/
        └── User/
            ├── custom.css##os.Darwin
            ├── keybindings.json##os.Darwin
            ├── settings.json##os.Darwin
            ├── snippets##os.Darwin
            └── tasks.json##os.Darwin

Describe the solution you'd like

The perfect solution in this case would be for me to rename my ~/.config/yadm/alt/Library to Library##os.Darwin, and then I could rename all of its contained files to their usual names without any ## suffix.

As described in #328, directories with an alternate name will have their direct children linked, but deeply nested directories are not supported. The documentation was updated to reflect that, so I guess this is an explicit request for the alternative: to support these kinds of directories instead.

Describe alternatives you've considered

Currently, I'm simply using alts where each file has a ## suffix, but it would reduce the need to use extension.* suffixes and generally look a lot cleaner if alts could link a whole directory recursively instead.

Additional context

From what I can tell, the decision of how/whether to link an alternate is done here in alt_linking: https://github.com/TheLocehiliosan/yadm/blob/master/yadm#L695-L702

If it would be accepted, I'm willing to try updating the implementation and open a PR! I guess this might be considered a "breaking change" of sorts, since it could end up linking new files that weren't before, but I'd guess it's pretty rare to have directories like this for most users.

Edit: looks like maybe the target/condition parsing would be most important here: https://github.com/TheLocehiliosan/yadm/blob/master/yadm#L170-L171 - probably would need to split at path separators and parse out the source/conditions a little more robustly. I'm not sure how this works for top-level files today?

[github-actions]

This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[ian-h-chamberlain]

Still interested in this feature, but the stalebot has reminded me I was going to try implementing this myself... Seems this repo hasn't been super active recently but maybe I will give it a shot anyway.

[erijo]

(Moving the discussion here instead of in the PR [#495].)

Regarding this comment:

there's no way to merge the linked directory, and if it already exists the symlink will be created as a child instead of what I thought the behavior should be (symlink all the children to their respective locations).

I now think that making the change to link each individual file instead of the directory is a non-backwards compatible change and also something that might not always be expected (when the whole directory is linked it's easier to see and add new files). We must then also handle the upgrade case where the directory is already linked.

Perhaps the way forward is to introduce an option to select the behavior one wants, possibly as a "condition"?

[ian-h-chamberlain]

I now think that making the change to link each individual file instead of the directory is a non-backwards compatible change and also something that might not always be expected (when the whole directory is linked it's easier to see and add new files). We must then also handle the upgrade case where the directory is already linked.

Perhaps the way forward is to introduce an option to select the behavior one wants, possibly as a "condition"?

Ah, interesting point, I guess it would be a change in behavior that might be surprising/breaking for people's existing workflow.

A new kind of "condition" would make sense to me as a compromise to enable this kind of functionality. I'd propose something like dir.merge or directory.merge, to avoid conflict with existing d (distro) and to be extensible to leave room for any future options for other "directory" conditions.

The upgrade scenario is an interesting to think about; I guess I'd assume that normally stale links should just get removed if they don't apply anymore, same as other alt files. I wonder what the current behavior is if the target directory for an alt already exists when linking happens?