Running `tuckr add` on a group with symlinks in it throws an error

[djsigmann]

I have a group which contains symlinks:

/home/djsigmann/.config/dotfiles/Configs/luarocks
└── .config
    └── luarocks
        ├── config-5.1.lua -> config.lua
        ├── config-5.2.lua -> config.lua
        ├── config-5.3.lua -> config.lua
        ├── config-5.4.lua -> config.lua
        └── config.lua

Upon confirming that ~/.config/luarocks does not exist and running tuckr add luarocks, I get the following error:

Conflicts were detected. Conflicting groups won't be added until conflicts are resolved.
Not Symlinked:
	luarocks	 -> /home/djsigmann/.config/luarocks/config-5.3.lua (symlinks elsewhere)
	 -> /home/djsigmann/.config/luarocks/config-5.4.lua (symlinks elsewhere)
	 -> /home/djsigmann/.config/luarocks/config-5.2.lua (symlinks elsewhere)
	 -> /home/djsigmann/.config/luarocks/config-5.1.lua (symlinks elsewhere)

Symlinked:
	luarocks

Check `tuckr help add` to learn how to fix symlinks.

Despite the error, the group is infact deployed correctly, and ~/.config/luarocks is a symlink to ~/.config/dotfiles/Configs/luarocks/.config/luarocks.
The same behaviour occurs if a symlink within the group has an absolute target or a target outside of ~, it makes no difference.

[RaphGL]

I'll have to take a look at this. My theory is that this is a problem with the validation. I never expected people to just symlink one file into another inside their dotfiles repo. So originally I would just consider any symlink that doesn't point exactly to the path it's supposed to be from as "not owned" and make the user resolve it themselves.

But at the end of the day if the symlink is correct (and doesn't point elsewhere recursively) and is inside its own group it should probably be valid.

[djsigmann]

To be fair, this IS an edge case, the only reason I structured that group like that is because luarocks NEEDS a separate config file for each version of lua, and since I want the specific settings I set to apply regardless of which lua version is running, I simply symlinked them to a common file.

In the majority of cases, symlinking files like this would indeed be strange and probably a bad idea (especially if the symlink target is outside of ~).

[RaphGL]

I'll still try to add this in there. I already plan on supporting detecting whether something needs root access anyway, so the program would figure out that it cannot go any further and report it to the user.
For the symlink though I'll probably need to add an arbitrary limit for symlinks so that I don't get in an infinite loop trying to read a borked symlink that's recursively pointing to itself.

So at least I hope that even if you shoot yourself in the foot by doing this tuckr can help. We'll see how it goes.

[krokosik]

I have a similiar issue when I try to setup gtk themes. In particular, a single theme is symlinked to different gtk versions and this also fails with tuckr. However, I use a workaround where I create symlinks with the post hook.

[djsigmann]

@krokosik Mind sharing your workaround? I'd like to take a look.

[krokosik]

@djsigmann sorry for not replying. I tested my setup some more and the workaround was not working as robust as I hoped so I gave it up. It was basically a bash script calling ln with all the relevant locations that nwg-look sets up. I now only have my theme in tuckr and use nwg-look manually to switch.

INFO[0002] >>> Exporting /home/krokosik/.config/gtk-3.0/settings.ini
INFO[0002] >>> Exporting /home/krokosik/.gtkrc-2.0
INFO[0002] >>> Exporting /home/krokosik/.local/share/icons/default/index.theme
INFO[0002] >>> Exporting /home/krokosik/.config/xsettingsd/xsettingsd.conf
INFO[0002] >>> Symlinking files in /home/krokosik/.config/gtk-4.0
INFO[0002] >>> Exporting /home/krokosik/.config/gtk-4.0/settings.ini