Install profiles

[justone]

It would be handy with some kind of install profiles thing where you can do dfm install work or dfm install home to get the work related dotfiles or so. Sure you can use different branches but since many of the files are in common it gets tedious in the long run to rebase/merge all the time across the branches.

[originally submitted by @erikw in the dotfiles repo]

[seth--]

Maybe instead of profiles we could have another command in dfminstall.
Something like
file.sh install-if shoud-install-or-not.sh

If should-install-or-not.sh exits with 0, install file.sh and skip it otherwise.
It's more complicated but also more flexible. For example, I may only want to symlink my sublime textconfiguration if the system has sublime installed and this allow to do it without knowing anything about the system beforehand.

[rneatherway]

I have this problem with files like my hgrc and gitconfig. This is partly needing to use different locations for the ssl certs for hg on different machines, and partly having different emails for work and home.

I like the idea of having a profile command in the .dfminstall files e.g:

README.md skip
.ssh recurse
work profile
home profile

The meaning would be that if you have selected profile X, then you include the contents of any directory named X and marked with profile as if they are in the current directory. So I would use a directory structure like:

.
├── home
│   └── .hgrc
└── work
    └── .hgrc

The profile could be prompted for on first encountering a profile command, and cached in .dfmprofile.

I can help with/carry out the implementation. What do you think of the idea?

[justone]

Hey,

I actually have a branch that I started over a year ago to add profiles. It handles what you need but also handles include and exclude modes as well. If I remember correctly, it was mostly working. I coded up a prototype but there were no tests, so I didn't merge it.

If you'll give me a couple of days to resync my brain into it, I should be able to give you a beta version that would work.

[rneatherway]

Ah, that sounds great. I would be happy to try it out and look for bugs.

[justone]

Ok, here is the link to the current work in progress: dfm.

There are three types of profiles: include, exclude, and overlay. The first will only install a certain list of files, the second will install everything but a certain list, and the third one is for your situation.

Here's how I would set up your example. First of all, I would assume that 'home' is the default and that work is an overlay, and that the 'home' version of the .hgrc file is in the root of your dotfiles repository. Then:

$ mkdir .dotfiles/work                        # make the work overlay directory
$ echo "work skip" >>  .dotfiles/.dfminstall  # skip the work directory so that it doesn't
                                              # get symlinked itself
$ cp .hgrc.work .dotfiles/work/.hgrc          # put the work version of the .hgrc into the
                                              # work overlay directory
$ dfm profile add work --overlay work         # add the work profile, specifying the work
                                              # overlay directory
$ dfm install --profile work                  # install the work profile, which will change the
                                              # .hgrc symlink to point at work
$ dfm install --profile                       # don't specify a profile to revert to the
                                              # home content

I also made profiles sticky, so that once you switch to the work profile, you don't need to keep specifying it when running dfm install or anything else.

I hope this makes sense. I had been trying to go a different direction before (mapping individual files instead of an overlay) and it just turned into a big mess. The overlay is a small tweak on your idea and I like it a lot more.

Please try it out. Of course, there's a small possibility that this beta version will eat your dotfiles for lunch, so do proceed with caution. 😉

Thanks for trying it out.

[rneatherway]

Thanks very much for this! I'll give it a go on Thursday

[rneatherway]

Hey, just tried this and it's working very nicely, thanks! I will keep using it day-to-day and let you know of any problems.

I wonder if it is possible to combine profiles? For example I might want to use the 'work' overlay in conjunction with the 'noinputrc' profile. I realise that this is getting into diminishing returns, but it would save having to possibly duplicate files if I have the following situation:

.gitconfig with work email, .gitconfig with personal email
.hgrc that includes SSL certs from Debian location, .hgrc that includes SSL certs from OS X location

then I might want to have a work/Debian install, a work/OS X install etc.

[justone]

Awesome, glad to hear it's working out for you.

I'll have to see how profiles can be combined. It could be a useful feature, but I can think of several cases where things can end up breaking. Just have to enumerate as many of them as I can in the tests and see how that goes.

I'll update this thread when I've made more progress.

[rneatherway]

I just ran into an issue with a more complicated structure. If I have folders in my overlay then they are not installed -- dfm doesn't seem to recurse through the overlay folder. Should that work?

[justone]

That won't work. Overlay, as it is implemented, will only look for files or folders that are present in the main dotfiles area. A workaround for now would be to add a matching folder in the main folder.

I'll see about how hard it would be to add in that feature.

[rneatherway]

Ah, makes sense. I tried adding a matching but empty folder structure in the main folder but that doesn't seem to work. Does the contents of the .dfminstall files matter? In the main folder I made them all be recurse to prevent them from having any effect there.

[justone]

All you should need are the matching folders. Adding recurse to .dfminstall may confuse things. If you keep having problems, could you show me what you have so I can try to figure out where it's stumbling?

[rneatherway]

The thing is that for this use case I don't actually want the folders to be symlinked if I don't have the overlay enabled, but just for the current situation to be left alone. This is why I added recurse in the standard copy of the folders. Does that make sense? If not I can make a little repro.

I might take a look over the code next week, see if I can extend it for that use case. I imagine that if multiple profiles could be enabled at once, each would be walked in lock-step along with the main directory. If multiple profiles clash, then it's an error, else profiles take precedence over the main directory. I agree it isn't quite obvious what to do if one profile/main dir says to recurse and another doesn't.