Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow stow to work both with paths outside of homedir and in the homedir #64

Open
ghost opened this issue Aug 16, 2019 · 1 comment
Open

Comments

@ghost
Copy link

ghost commented Aug 16, 2019

Hi, Apologies if this is a dumb question/issue

My usecase is this:
I have a directory called "dotfiles" in my homedir, this is managed by stow and all packages in it are located in my homedir so no stowrc tinkering is needed

I have another directory called "dotfiles-extra" which manages packages outside of the homedir
Since the packages here need to be in /etc which is outside of my homedir and starts with a /, i need to use a stowrc to manually set the target.

So i use --target=/ ssh in my stowrc to stow my ssh config file to /etc/ssh with the contents of "ssh" being etc/ssh/sshd_config

The issue I'm having is I am trying to merge both directories into one big dotfile directory for ease of use/access but I can't seem to use stow with both homedir targets and targets outside of the homedir, this could possibly be solved if stow could check if the first directory in a package is called ROOT or another keyword and this would indicate to stow that the package should be linked outside of the users home directory, that way you could just run stow ssh as normal.

This would mean if I wanted to stow my ssh config the package dir would look like this ROOT/etc/ssh/sshd_config and would symlink to /etc/ssh/sshd_config

(I'd try implement this myself but my perl knowledge is very limited)

I've read through the manpage a few times and experimented many times with various methods but my best solution is to keep packages that require a location outside of the homedir in a separate repo with a stowrc that specifies the target outside of $HOME.

Would it be possible to use stow on a single repo that contains both non-homedir packages and homedir packages without using a different stow command for each package?

Apologies if this sounds like gibberish, I thought it'd be easier to explain before I typed all this up.

@rawtaz
Copy link

rawtaz commented Dec 5, 2020

I have the same type of use case. In my ~/dotfiles/rofi/.config/rofi/config (which I stow with ~ as the target directory, all default settings) there's a reference to a theme file for rofi, which has the path /usr/share/rofi/themes/Pop-Dark.rasi.

I would like to keep this themes file in my dotfiles directory (as it's part of the rofi configuration), but the only way currently to do this is to use / as the target directory when running Stow, and of course modifying the paths in/under the ~/dotfiles directory (e.g. ~/dotfiles/rofi/.config/rofi/config to ~/dotfiles/rofi/home/USERNAME/.config/rofi/config). Besides not needing to use / for much else, making it a shame having to deviate from default settings, it also requires that I hardcode a username in the path in the packages, which isn't great.

I see there's a s/^dot-/./ feature in stow that one can enable using the --dotfiles argument. Perhaps one solution to the use case would be to have a similar parent- prefix that would be substituted for ../ when Stow evaluates paths, enabled using e.g. --parents or similar argument.

I would however also suggest to enhance the --dotfiles and --parents or similar arguments to take a parameter with the prefix name, e.g. --dotfiles=dot- and --parents=parent- to enable s/^dot-/./ and s/^parent-/..\// when evaluating paths. In case one would need a path to a dotfile with e.g. parent- in the name, one could then do --parents=myParentPrefix- or similar to enable s/^myParentPrefix-/..\// instead of s/^parent-/..\//.

Does this make sense? Let me know if I need to clarify. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant