Thanks for the comments.
The way I was thinking of it is that the individual cookbook is embedded in
a larger surrounding project, so that the “core” cookbook directory could
be pulled out and zipped up without much logic concerning which
files/directories belong to the “core” cookbook and which files/directories
belong to the larger surrounding project. This would make the work of a
"rake upload" type task much easier.
If, instead, everything is at the toplevel, that will require extra logic
when zipping and pushing a release. But it will make the project structure
I wouldn’t embed everything deep down in cookbook/COOKBOOK-NAME; unless
there’s something I’m missing, I would either embed just the "core"
cookbook there or keep everything at the top-level. This is for repos
containing exactly one cookbook, following the repo-per-cookbook pattern.
Either way, let me know how easy/hard it is to integrate Vagrant & Toft
with the Cheffile (in case you or others plan to have one), and based on
your experimental results what can be done to improve that integration.
One thing I am considering is a metadata DSL method that would read the
metadata.rb from the same directory, so you wouldn’t have to spell out all
the dependencies in the metadata.rb and then do so again in the Cheffile.
This would follow the pattern of Bundler’s gemspec DSL method. I can see
this being useful for the Cheffile belonging to an individual cookbook repo.
# apply all the dependencies listed in ./metadata.rb
# these all use the default source listed above
# override the source for one of the cookbooks listed in ./metadata.rb
# e.g. in case we need a specific fix when developing & testing the
:git => “https://github.com/opscode-cookbooks/apache2”,
:ref => “be12fede2e99aff3029360df38366a3b8a34171f”
On Wed, Apr 25, 2012 at 2:14 PM, Bryan Berry firstname.lastname@example.org wrote:
hmm, I have something different in mind
Jay, like we talked on the podcast, I think cookbooks need to be
self-contained. Here is how I think it should be laid out
I definitely think that the Vagrantfile, Toftfile (my own invention),
and Cheffile should live at the cookbook/COOKBOOK-NAME/ level
temp/ # cache
cookbooks sourced by Cheffile
tests or test? don’t know the convention
. . .
same as Vagrantfile but for toft
The Cheffile at the at COOKBOOK-NAME level would be used by
Vagrantfile or Toftfile to source the other cookbooks needed to run
that’s my euro 0,02
On Wed, Apr 25, 2012 at 7:53 PM, Jay Feldblum email@example.com
It may be wise to structure the Git repository of tested cookbooks
to the following convention:
# for cookbooks installed via librarian-chef
# this is an assumption librarian-chef currently makes
# to support Vagrantfile
# the cookbook under test may depend on other cookbooks
# don’t add to git in a cookbook repo
# only add to git in an infrastructure repo
# has a task for zipping up the content of cookbooks/COOKBOOK-NAME
# and optionally for releasing to the Opscode Community Site
# if using Vagrant for testing
# references cookbooks located in cookbooks/ (dependencies) and
cookbook/ (under test)
If people think this is a good idea, I may add intelligence to
Librarian-Chef’s git source to try to find the cookbook inside
cookbook/COOKBOOK-NAME/ if it can’t find the cookbook at the top-level of
the git repo. However, for now, people can always use the format:
:git => “git://github.com/user/COOKBOOK-NAME”,
:path => “cookbook/COOKBOOK-NAME”