Turns out that many many many tools want config files named after them. I can't help but think this is a very special form of narcissism. In this repo, I hope to assemble a repo consisting only of these files (with the exception of their .lock files if the tool requires them), and make them do something in an orchestrated fashion -- note that this says "something", not necessarily "something useful".

To run this

(and why would you want to do that?)

You'll need VirtualBox 4.2.x (or 4.3, though you will get warnings; I'm testing on 4.3 and it works fiiiiiine).

Then, run:

make fetch happen

TODO

Only an excerpt. See Filefile for a complete list.

• Capfile
• Gruntfile
• Guardfile
• Procfile

Done - for "serious"

• Berksfile
• Dockerfile
• Gemfile
• Makefile
• Vagrantfile
• Rakefile
• Thorfile

Done - really not even "serious"

• Catfile
• Manifestfile (when given the choice between this & site.pp...)

Exceptions made

Life is full of compromises. There are some files that don't fit into this naming scheme, no matter how much I try to bend the universe over backwards:

• *.lock because of course
• .gitignore
• README.md - it's a symlink to Catfile.

What does this repo even do?

It follows the naming scheme to its gruesome logical conclusion: It serves the tool's purpose, and not your own. Whatever utility you get out of each tool is dictated by what each tool thinks you should be doing. Hence.

1. Make runs "bundle install" and brings up a Vagrant box
2. Vagrant provisions docker
3. Docker brings up a container running Guard. Docker is provisioned as follows:
4. We add Berksfile, Thorfile, Rakefile to the container
5. thor & berkshelf install the chef cookbooks necessary to provision the docker container
6. rake chef:prepare runs & generates the files necessary to configure the machine
7. chef-solo runs and applies the rules (it installs ruby 1.9.3 only at the moment).

I have no idea what Grunt and Capistrano would do at the moment, but they'll be busy later, I'm sure.