thoughtbot / rcm

rc file (dotfile) management
https://thoughtbot.github.io/rcm/rcm.7.html
BSD 3-Clause "New" or "Revised" License
3.12k stars 136 forks source link

Using .dotfiles/rcrc #103

Closed hugelgupf closed 10 years ago

hugelgupf commented 10 years ago

When I first clone my .dotfiles repo, I have to symlink .rcrc to .dotfiles/rcrc manually. That's a bit of a hassle, why not look at .dotfiles/rcrc (or, well, $DOTFILES_DIR/rcrc) when .rcrc does not exist?

Edit: I suppose the tricky part here is supposed to be the -d option, which is not processed until after rcrc is needed.

rspeicher commented 10 years ago

I was thinking it might be handy to add a "bootstrap" option (-b is available) which looks for an rcrc file in the directory specified by -d and recognizes useful options like EXCLUDE_FILES.

This would change the initial install line for thoughtbot/dotfiles from

rcup -d dotfiles -x README.md -x LICENSE -x Brewfile

to

rcup -d dotfiles -b

Or you can make it automated if ~/.rcrc doesn't exist but $DOTFILES_DIR/rcrc does and remove the option altogether. That might be smart.

pablox-cl commented 10 years ago

I don't have any problems linking the file by hand. In fact, I found useful to stop and think in what I'm doing.

mike-burns commented 10 years ago

It's an environment variable currently: RCRC. I show an example elsewhere: https://github.com/thoughtbot/dotfiles/pull/288#issuecomment-50034436

pbrisbin commented 10 years ago

I use the RCRC feature for this. In case it's not clear, here's an example of me "bootstrapping":

% RCRC="$HOME/.dotfiles/host-$(hostname)/config/rcrc" rcup

This example also shows that it's not as simple as your suggestion anyway.

hugelgupf commented 10 years ago

@tsigo that is what I was thinking; no option, but automatic. @pbrisbin I should learn to say what I mean instead of simply assuming. I was thinking that -d could be used to override the dotfiles dir, so it'd be rcup -d "$HOME/.dotfiles/host-$(hostname)/config/" in your case. Either way, I don't think there is a big advantage to what I initially proposed anymore. Yet also it wouldn't be that hard to implement and at least in the default case it'd be a small improvement. But a really small one, so I don't think it helps a lot.

I think what should happen is that the rcm(7) should show the RCRC usage for bootstrapping.

mike-burns commented 10 years ago

I would definitely take a PR for any of the following:

I'm closing this issue in the meantime. Thanks for bringing this up!

pablox-cl commented 10 years ago

I like env varzz :(

bcomnes commented 10 years ago

I would like to see rcup followed by an rcdn followed by an rcup result in the correct state based on implied rcrc settings locations. Right now, it does not.

This requires a few things:

1) host specific dotfiles should override global dot files (see https://github.com/thoughtbot/rcm/issues/94) 2) Assuming 1), if ~/.rcrc does not exist, then check for ~/.dotfiles/host-[hostname]/rcrc. If found, use it. If not, look for ~/.dotfiles/rcrc. If thats found, use settings found in it. If not, use default settings. 3) Specifying a folder rcup -d ~/otherdotfiles when bootstrapping would run the process in 2) except in a different folder. 4) Allow this implied behavior to be overridden with flags or ENV vars.

Bootstrapping is a major pain point and its something I think that rcm could easily manage.

An alternative approach is to read ENV vars after the pre-up is run so that bootstrapping behavior like this could be achieved only with hooks. Right now, hooks can't be used for changing settings on rcup.

pbrisbin commented 10 years ago

Bootstrapping is a major pain point and its something I think that rcm could easily manage.

I respectfully disagree here. RCRC=whatever-you-want rcup is an effective, transparent, and simple way to bootstrap. I still haven't seen a specific pain point with that approach.

I'd love to phase out the env var eventually.

Why? This not only helps the bootstrap case, but also allows me to have the rcrc file where I want (I like to follow xdg) in a constistent way. I'm not arguing that's it's objectively better than a flag, but I'd be sad to see support for it dropped in favor of a flag only.

bcomnes commented 10 years ago

I think major was a bit of an exaggeration, but I think rcm could do better, or at least be more consistent. Bootstrapping with ENV vars isn't really that bad or hard, and should totally be an option that does not go away (I'm indifferent about the ENV vs flag though).

rcm could be made simpler by extending certain behaviors that rmc already uses. Having to remember to manually set temporary and host specific ENV vars to bootstrap an automation system seems contradictory to the primary goal, which is an automated process to install dotfiles in my different environments.

Right now rcm makes use of implied settings until configured with the .rcrc file or is modified with flags and env vars.

Upon bootstrapping, rcm, in its current state, behaves pretty strangely. Here is how it works today.

1) I clone my .dotfiles to my homedir.

2) I run rcup, which begins linking everything from the assumed location ~/.dotfiles into my home folder, including all files that have been listed as ignore files in the ~/.dotfiles/host-[hostname]/rcrc file. Because rcup didn't see a ~/.rcrc file and $RCRC was unset, I now have a bunch of symlinks in my home directory pointing to files that should have actually been ignored (some of which are now stashed under folders and are not easily spotted with ls -la). Currently the only way to avoid this is bootstrapping with RCRC set.

3) To make matters worse, since ~/.dofiles included an rcrc file which is now correctly linked to ~/.rcrc, when I run rcdn to undo the mess, rcdn only removed files that it was told not to ignore, leaving behind a mess of symlinks to files that should have been ignored.

This is also a problem when pointing any of the rcm tools to non-implied folders with the -d tag.

This whole situation could be easily be avoided by allowing rcup to preemptively look for the correct rcrc file if no ~/.rcrc file already exists in order to enable automatic bootstrapping when following implied locations (IE cloning your dotfiles to ~/.dotfiles). Is there any reason not to default to those found rcrc settings anyway? What situations would that be useful in? It would still allow for overrides with the $RCRC env var (or flag in the future). It wouldn't affect anything once the ~/.rcrc link is made. You could add another flag to disable this bootstrapping feature just in case.

I think it comes down to this. Right now we have:

> git clone dotfiles ~/.dotfiles
> RCRC=~/.dotfiles/host-computer/rcrc rcup

I would like to see the ability to do this:

> git clone dotfiles ~/.dotfiles
> rcup  #

Thoughts?

docwhat commented 9 years ago

I just use this hooks/pre-up/rcm-configure:

#!/bin/bash

set -eu

pushd "$(dirname "$0")" > /dev/null
cd ../..
dotfiles_dir="$(pwd)"
popd > /dev/null

if [ ! -f "${HOME}/.rcrc" ]; then
  echo "INFO: Installing default ~/.rcrc file" 1>&2
  cp "${dotfiles_dir}/rcrc.example" "${HOME}/.rcrc"
fi

Which copies rcrc.example to ~/.rcrc.

sudomateo commented 5 years ago

Given a ${HOME}/.dotfiles/rcrc file I use:

$ cd
$ rcup rcrc
$ rcup