[Question] Best practice for tracking both local and global dotfiles?

[mhelvens]

I apologize if this is outside the scope of this repo. Go ahead and close, if that's the case.

I want to track the configuration files on my pc, and sync them to GitHub. I've been successfully using rcm for this, in a ~/.dotfiles folder which doubles as a git working copy. But this can't capture global dotfiles very well. And unfortunately, there are some I just can't move to my home dir (like /etc/bluetooth/main.conf).

I know I can set up another dotfiles directory and list it in DOTFILES_DIRS, but then I'd need to maintain two separate GitHub repos for this, which seems strange. Storing both global and local dotfiles in the same dir seems to mix up namespaces in a weird way. (Like both / and ~/ are considered root by mkrc?)

I can think of other solutions, but they become increasingly hacky. Is there some established best practice for this scenario? Do people simply maintain two repos? Do they mix namespaces and hope there's never a clash? Do they put multiple dotfile dirs one level below their git working copy?

[alexfornuto]

If I were you, I would use two separate repos, and have a master repo with these as submodules to quickly import them both to new systems.

[mhelvens]

@alexfornuto: Sure, that's an idea. I'm still curious how other people actually do it on their own machines, and what is recommended by the rcm devs. 😄

[dgrabla]

At the moment I have a few global (/etc) configuration files per machine managed by RCM mixed with personal dotfiles. This has the problem that I need to symlink them to their expected locations on /etc by hand. This is not a good solution because of the extra manual work and the issue with the permissions - sometimes they are expected to be owned by root.

The solution we discuss here with two RCM repos, one for personal files with your normal user and another for global files with root is also not great because rcup will copy/symlink to /root and AFAIK there is no way to specify a dfferent target folder (NOT in /root but instead target /etc).

@mike-burns A feature to specify a target folder to rcup instead of the default $HOME looks like a terrific addition. That will allow the root user to manage global dotfiles. Can you think of an alternative workaround?

[mat-m]

I suppose you can symlink /etc in /root to have /root/etc and bind your global dotfiles from here, keeping two repos, one for root, one for you.

[mike-burns]

TBH I'm not excited about the idea of using rcm for things under /etc. I'd probably use e.g. chef for that.

I would be open to a PR that allowed the user to specify the target directory.

[eddsalkield]

Another advantage: allowing the user to specify the target directory lets rcm track dotfiles whose target locations may depend upon the values of environment variables, e.g. $XDG_CONFIG_HOME.

I propose three methods for specifying the target: Firstly, a meta-file at path_to_dotfiles_dir/target for every dotfiles directory. This file specifies the new target to install dotfiles from this directory to. If the target meta-file is not present, the default target will be used instead. The path within the meta-file will be expanded with relevant variables from the current environment. Then come options for specifying the default target, which is overridden by the target meta-file: Secondly, an option TARGET in rcrc. Thirdly, a command line option (potentially -T) for all four utilities.

Therefore we achieve the desired result, with rcm-wide and per-dotfile granularities.

A wider question: does it make sense to group all meta-files into a single meta directory within each dotfiles directory? Having rcm never look there for dotfiles will prevent any collisions between future meta-files and existing user dot files.

[mike-burns]

A wider question: does it make sense to group all meta-files into a single meta directory within each dotfiles directory?

It was a mistake for rcm to mix files like it does, but it's a mistake that's in place now. Changing it would be a breaking change and I'm not convinced it's worth it.

I like the TARGET option in rcrc(5) and the -T flag.

What's the case for the manifest target file?

[eddsalkield]

Suppose I wish to have my dotfiles be installed within $XDG_CONFIG_HOME, which defaults to $HOME/.config if the environment variable is not set. This is a very common case; applications are increasingly adopting the XDG Base Directory Specification. Currently rcm could install dotfiles to $HOME/.config, but would be unable to change the target based on an environment variable.

It is possible with an rcm-wide feature like the TARGET option or -T flag, at the expense of being able to also install dotfiles to $HOME in the same invocation of rcm.

Using a manifest target file, the user could maintain one dotfiles directory for the XDG locations, and one for the old $HOME locations, since he now can specify a target for each dotfiles directory individually. Furthermore, if the behaviour of rcm was to find the first line in the target manifest that references a directory, then a target file could be constructed to install the dotfiles to $XDG_CONFIG_HOME, falling back to the correct default if the variable is not set.

This also solves the original question of the thread, again without requiring multiple invocations of rcm per desired location.

I created a patch yesterday that implements these three target methods; if you're convinced, I shall submit it shortly.

[mike-burns]

Oh wow, interesting. OK.

I'll definitely take a look at this PR, but if that target file codepath is too complex we'll have to discuss it further.

Thank you for working on this!

[galk-research]

This is a good feature, IMHO. I am a new rcm user, and while I do not intend to target outside $HOME, specifying a target somewhere under $HOME, such as $XDG_CONFIG_HOME, is indeed important. I currently have some files and some directories under ~/.config/ (sometimes, under ~/.config/.../) that are part of my work environment.

Indeed, ability to have separate rcrc for different dotfile directories, with separate TARGET, would be the killer feature. I have too many undotted folders and files I wish to use rcm with, and right now, the way to automate their linking, I either have to use -U manually, or put them into the common (global) rcrc.

[baltazarortiz]

Agreed! Currently I just locally realias rcup and lsrc to include -t local_tag_name but it doesn't feel very elegant