Create symlinks with absolute path names

[fourzerofour]

Can we have an option to create symlinks with absolute path? When your stow dir is not in the default location which is /usr/local/stow, I think it's more efficient to use absolute path in the target path when creating symlinks

$ cd /opt/stow/jvm
$ stow -v1 -n -t /usr/local jre1.8.0_05
...
LINK: bin/java => ../../../opt/stow/jvm/jre1.8.0_05/bin/java

EDIT: Clarification from @aspiers:

• This issue is about the symlinks which Stow manages in the target directory being absolute symlinks.
• Should we add support stow directory is symbolic link. #11 is about the Stow directory being a symlink.
• Support package trees containing absolute symlinks #51 is about package trees containing absolute symlinks.

They're all separate issues despite appearing similar on the surface.

[aspiers]

Interesting idea. Why do you think it would be more efficient?

[hongyi-zhao]

Dear aspiers,

Several days before, I've discussed the similar issue as posted in this thread. Now, I give a concrete example as follows:

When using systemd, we may create some customized service unit files, say, I've create the following service unit file just for testing:
werner@debian-01:~/test-systemd$ cat test-systemd.service
[Unit]
Description=test for systemd
[Service]
ExecStart=/usr/bin/env bash -c "echo blabla > %h/1111111"
[Install]
WantedBy=multi-user.target

If I want to use stow to maintain this customized service unit file and put it in the non-standard locations which systemd cann't searches in its path, I must link this file to appropriate location so that systemd can recognize this service.

On the other hand, systemd in itself can only support the absolute path symlinks for such case.

You can see the systemd will create the following absolute symlinks for this service file:

werner@debian-01:~/test-systemd$ systemctl --user enable ~/test-systemd/test-systemd.service
Created symlink from /home/werner/.config/systemd/user/multi-user.target.wants/test-systemd.service to /home/werner/test-systemd/test-systemd.service.
Created symlink from /home/werner/.config/systemd/user/test-systemd.service to /home/werner/test-systemd/test-systemd.service.

So, if using stow to maintain this type of file and create the relative symlinks to the target locations, systemd won't work on this service file.

Regards

[simonvanderveldt]

@aspiers Would you consider adding the option to create absolute symlinks? It's the only feature that's in xstow that I miss with GNU stow.

The reason/usecase for me is that I run a lot of development tools in a (Docker) container.
In many cases I need some config inside the container, which can be done with a volume mount of that file, but since that config file is actually a relative symlink created by stow (which goes "up" the hierarchy) the symlink is there but it's impossible to access the real file.
If you need some more info/context just let me know.

[aspiers]

Yes sure, I'm all for extending Stow in ways that people find useful (regardless of whether I personally find it useful!), as long as it doesn't create any serious technical debt or issues with existing use cases (and I don't expect it would in this case).

I'm incredibly busy at the moment, so this short note is mainly an apology that I can't look at this more closely right now. I tend to process my Stow backlog in batches, ideally every 3-6 months or so (Donald Knuth style) but less often in practice - and the next one is sorely overdue. But if there is a pull request to review at that point which adds this then I'd happily review, otherwise if it looks quick and easy to fix myself then maybe I can do it but no promises!

[bricewge]

An other use-case is maintaining a $GIT_TEMPLATE_DIR with stow. Since git will copy the content of $GIT_TEMPLATE_DIR, when initializing a new repo, it copies the relative symlinks to $GIT_DIR all of which will be broken in most cases.

[aspiers]

I've finally thought about this some more, and need some more info from the people requesting it:

• I would like to hear from @fourzerofour regarding efficiency concerns.

• @hongyi-zhao - the systemd use case is interesting but I don't fully understand it yet. Please can you explain why and how you would want to use Stow to manage systemd service files? Do you mean you want to use Stow to install symlinks instead of using systemctl --user enable, or do you mean you want Stow to manage symlinks under ~/test-systemd? It would be very helpful if you gave a full example of exactly what you want Stow to manage, including example paths for all files/symlinks involved.

• @simonvanderveldt your case is also interesting but again I don't understand it. If you are mounting a config file from a Docker host into a container, even if that config file is an absolute symlink it will still point to a path which the container can't reach. Please could you give a full example of how you want it to work, including example paths for all files/symlinks involved?

• @bricewge So you want to have a template directory which contains absolute symlinks managed by Stow, so that when you git init using that template directory, your new repository gets the same absolute symlinks pointing to files outside the repository? Why would you want a git repository to contain absolute symlinks which point outside it?

I'm definitely open to Stow being extended to support these use cases, but it's a non-trivial piece of work, so I first want to make absolutely (pun intended) sure that the feature is justified and makes sense. Thanks in advance!

[bricewge]

Yes you got it right. I need this to manage my git hooks centrally and not on a per repo basis.
You can see my current use in this package: _template dir and setup.sh are ignored by stowed and allow me to workaround this issue. What I would like to acheive when this issue is resolved is to have _template renamed to .config/git/template which is my git templateDir.

For what I understand the systemd used case submitted by @hongyi-zhao can already be acheived. I'm currently successfully using stow to manage user services under systemd 239 that are enabled by default.You can found part of my setup here and following is an example of it working:

$ tree  ~/.config/systemd/
/home/bricewge/.config/systemd/
└── user
    ├── graphical-session.target.wants
    │   └── polybar@.service -> ../../../../project/dotfiles/bspwm/.config/systemd/user/graphical-session.target.wants/polybar@.service
    ├── polybar@.service -> ../../../project/dotfiles/bspwm/.config/systemd/user/polybar@.service
    └── tmux.service -> ../../../project/dotfiles/tmux/.config/systemd/user/tmux.service
$ systemctl --user status polybar@HDMI1.service
● polybar@HDMI1.service - Poybar, create a status bar per monitor
   Loaded: loaded (/home/bricewge/.config/systemd/user/../../../project/dotfiles/bspwm/.config/systemd/user/polybar@.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-06-22 17:59:37 CEST; 5 days ago
 Main PID: 2703 (polybar)
   CGroup: /user.slice/user-3013.slice/user@3013.service/polybar.slice/polybar@HDMI1.service
           ├─2703 /run/current-system/sw/bin/polybar --reload example
           ├─2716 sh /home/bricewge/.local/bin/mpvctl.sh
           ├─2735 sh /home/bricewge/.local/bin/mpvctl.sh
           └─2736 /bin/sh /home/bricewge/.local/bin/mpvctl prop filtered-metadata
[...]

[aspiers]

Thanks a lot for the quick reply @bricewge! I'm not sure I'm any closer to understanding why the feature requested in this issue is needed though:

@bricewge commented on June 28, 2019 3:25 PM:

Yes you got it right. I need this to manage my git hooks centrally and not on a per repo basis.
You can see my current use in this package: _template dir and setup.sh are ignored by stowed and allow me to workaround this issue.

Sorry, maybe I'm being stupid but I still don't get it. What is the issue exactly, and how do they work around it?

What I would like to acheive when this issue is resolved is to have _template renamed to .config/git/template which is my git templateDir.

What's stopping you doing that right now?

For what I understand the systemd used case submitted by @hongyi-zhao can already be acheived. I'm currently successfully using stow to manage user services under systemd 239 that are enabled by default.You can found part of my setup here and following is an example of it working:

$ tree  ~/.config/systemd/
/home/bricewge/.config/systemd/
└── user
    ├── graphical-session.target.wants
    │   └── polybar@.service -> ../../../../project/dotfiles/bspwm/.config/systemd/user/graphical-session.target.wants/polybar@.service
    ├── polybar@.service -> ../../../project/dotfiles/bspwm/.config/systemd/user/polybar@.service
    └── tmux.service -> ../../../project/dotfiles/tmux/.config/systemd/user/tmux.service
$ systemctl --user status polybar@HDMI1.service
● polybar@HDMI1.service - Poybar, create a status bar per monitor
   Loaded: loaded (/home/bricewge/.config/systemd/user/../../../project/dotfiles/bspwm/.config/systemd/user/polybar@.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-06-22 17:59:37 CEST; 5 days ago
 Main PID: 2703 (polybar)
   CGroup: /user.slice/user-3013.slice/user@3013.service/polybar.slice/polybar@HDMI1.service
           ├─2703 /run/current-system/sw/bin/polybar --reload example
           ├─2716 sh /home/bricewge/.local/bin/mpvctl.sh
           ├─2735 sh /home/bricewge/.local/bin/mpvctl.sh
           └─2736 /bin/sh /home/bricewge/.local/bin/mpvctl prop filtered-metadata
[...]

Right, so why is there a need for Stow to be enhanced to support this further?

[bricewge]

I apologize, I wasn't clear enough it only doesn't works when using --no-folding. Flowing is an example to reproduce my issue with git templates.

1. We setup the stow package:

$ mkdir stow-3
$ mkdir -p .config/git/template/hooks
$ echo "#/usr/bin/env polybar --help sh\necho foo" > stow-3/.config/git/template/hooks/pre-commit
$ chmod +x  stow-3/.config/git/template/hooks/pre-commit
$ stow --target ~ stow-3 --verbose --no-folding
MKDIR: .config/git/template
MKDIR: .config/git/template/hooks
LINK: .config/git/template/hooks/pre-commit => ../../../../tmp/stow-3/.config/git/template/hooks/pre-commit

2. Creating a repo at the same level as the package will work:

$ cat -A repo/.git/hooks/pre-commit
#/usr/bin/env polybar --help sh$
echo foo$
$  ls -alh repo/.git/hooks/pre-commit
lrwxrwxrwx 1 bricewge users 60 06-28 16:48 repo/.git/hooks/pre-commit -> ../../../../tmp/stow-3/.config/git/template/hooks/pre-commit

3. But creating a repo on an other level the hook will be a broken symlink:

$ cd /tmp
$ git init --template ~/.config/git/template repo
Initialized empty Git repository in /home/bricewge/tmp/repo/.git/
$ cat -A repo/.git/hooks/pre-commit
cat: repo/.git/hooks/pre-commit: No such file or directory
$ ls -alh repo/.git/hooks/pre-commit
lrwxrwxrwx 1 bricewge users 60 06-28 16:50 repo/.git/hooks/pre-commit -> ../../../../tmp/stow-3/.config/git/template/hooks/pre-commit

Sorry, maybe I'm being stupid but I still don't get it. What is the issue exactly, and how do they work around it?

My workaround is a stupid script that get executed after stow because I'm using wrapper to run it.

Right, so why is there a need for Stow to be enhanced to support this further?

There is no need for it for using stow to manage systemd user services as far as I understand but it still seems needed to manage git template directories.