heavywater/pennyworth — pull request #6 by patcon (2011-12-04 20:15:56+00:00)
Title: Moved cookbooks out of dir and into Cheffile.

No docs yet, and honestly, haven't had a chance to actually test, as boot-up seems to take quite a long time, and it's a lot to do before knowing whether your cookbooks are even modified from the canonical opscode versions :)

I've been meaning to write something up on what I've found to be a good librarian-chef workflow, but here's the gist (helps keep modifications and overrides obvious, and allows for simple development):

|-cookbooks/ (in .gitignore)
|-cookbooks-overrides/
| |-[cookbook_fragments_for_overrides]
|-cookbooks-sources/
| |-[flat_directory] (like your postfix in my pull request)
| |-[git_submodules] (presumeably this would be fitting for your pennyworth cookbook)

So basically, `cookbooks` stay out of vers control, and librarian-chef builds it on fresh git clone, or after pulling an update to the `Cheffile`. If you makes slight changes to a canonical cookbook, you add those changes into `cookbook-overrides` (which is the second `cookbooks_path` in your knife.rb or Vagrantfile, so it overrides correctly).

`cookbooks-sources` is referenced in the Cheffile using the `:path` property. You can keep non-version-controlled cookbook directories in this dir, but ideally, you'll be placing git submodules in this dir. That way, you can more easily improve your project and tag when appropriate. I tend to put actively developing cookbooks in this dir, as it's simple to bump versions then test out changes, then tag and push when everything works fine. When a cookbook stabilizes (or you don't plan on changing it very often), you can change the reference in the Cheffile to look for it on the community site (assuming you've pushed it there), or you can just add a git reference to your stable tag.

I guess the idea is that this makes it simple for someone to not only see what your project is built from, but also take your project and merge it into their chef-repo (assuming they're also using librarian-chef to manage it). If your project versions are the same as my repo, sweet -- I just pull in the roles. If not, I update accordingly. But it's much less confusing where things have changed, and users can see at a glance instead of keeping track of bunch of diff runs. :)

Anyhow, sorry for the tangent, but I think it's worth looking into!

Cheers!