| I'm more or less using your approach, Jeremiah. The friction I ran into was when I wanted to roll a new release of a cookbook I manage (linode) from a git repo. The "knife cookbook metadata [ linode | . | -o ./ linode | metadata.rb]" commands wouldn't generate a metadata.json file for me. It wanted the cookbook to be in cookbooks/linode relative to cwd. Hence my "tied to a particular directory layout" comment.
So that sent me down the librarian-chef :path => (sorry, I couldn't resist), which then had different behavior than I expected given its similarity to the bundler option of the same name.
For the specific case of metadata.json generation, it would be nice if knife would work directly on a metadata.rb file. That would at least solve my immediate issue. And I'm sure I'll learn to live with the way L-C works. Overall it's a big improvement over what I was doing before.
Wes On Jun 22, 2012, at 1:52 PM, Jeremiah Snapp wrote: I've still been really pleased with the way I use Librarian-Chef. I let it take over my cookbooks directory within my chef-repo and make sure I don't version control that directory so instead it is just a "build artifact" as Jay calls it. I keep the chef-repo/cookbooks directory as the only cookbook_path in my knife config so I can easily 'knife cookbook upload -a'.
There are two locations for cookbooks I am developing.
- Forked Cookbooks which I put outside my chef-repo directory under ../cookbooks and then I use :path in Librarian-Chef Cheffile to bring those into the chef-repo/cookbooks "build" directory.
When I'm done developing these cookbooks I push them to the git server and change their entries in Cheffile to :git entries. - Private? Cookbooks which I put inside my chef-repo/site-cookbooks directory so they get version controlled with the rest of the chef-repo. These Cheffile entries are permanently :path entries regardless of whether or not I'm making changes to them.
If I make changes to either of these two types of cookbooks and I want to test those changes I just run "librarian-chef install" and the chef-repo/cookbooks build directory picks up all the changes.
Then I can either run "chef-solo", "vagrant provision" or "knife cookbook upload -a" depending on how I'm testing.
I understand what you mean but I wouldn't say knife is "tied to a particular directory layout". You can add the -o option to knife subcommands to specify what paths to look for the cookbook.
I find that is a small inconvenience compared to the flexibility otherwise provided by Librarian-Chef and my usage.
I don't bother with the Librarian-Chef knife integration pretty much just because I don't like that I can't run many (all?) knife commands unless I'm in the chef-repo where librarian-chef has been initialized. The knife commands just break and I find that to be too restrictive.
Jeremiah
On Fri, Jun 22, 2012 at 1:24 PM, Wes Morgan <
" target="_blank">
> wrote:
Thanks for your clarifications. I understand most of it, and I'm not actually asking for those things to be changed. I don't think. :)
What I really need, and what I should have said first:
With bundler, when I specify a :path => option, it just uses the code in that path directly. Is there a reason Librarian-Chef can't do that and instead copies it into the cookbooks dir? If there were just the one directory for the path'd cookbook, that would pretty much solve my problem. It sounded like the L-C knife integration could manipulate knife's cookbook path, so I was surprised it didn't do that and just point it at the directory specified in the :path => option.
Wes
On Jun 22, 2012, at 1:04 PM, Jay Feldblum wrote: Wes,
Librarian-Chef takes over your repository's ./cookbooks/ directory by design. It is no longer your directory. It is no longer source code. It no longer belongs to the source repository. It is now a build artifact that is produced by Librarian-Chef on your behalf, on-command, as per the instructions you give to it on the command line and in your Cheffile. The readme talks more about this and gives some tips for dealing with cookbooks you are working on: https://github.com/applicationsonline/librarian.
A future version of Librarian-Chef may allow you to configure the choice of directory.
Librarian-Chef assumes that you have a way to develop and test the underlying cookbooks independently of any consuming infrastructure repository. Sadly, the state of the world is not yet such that most cookbooks are developed this way. So there will be some friction over the near term, friction like the kind you have discovered, as the state of the world progresses in that direction.
Until then, the options available may seem like a choice between, on the one hand, a whole lot of work in testing a cookbook fork independently and in isolation and, on the other hand, hacks with the git and path sources in your Cheffile.
Cheers, Jay On Fri, Jun 22, 2012 at 12:05 PM, Wes Morgan <
" target="_blank">
> wrote:
I have yet to find an ideal setup for this, but librarian-chef is oh so close.
When you are actively developing a cookbook (or modifying a fork, etc.), you need a git clone from which you can push and pull. This should be the same directory where knife expects to find the cookbook so things like "knife cookbook metadata" will work as expected (knife should arguably be less tied to a particular directory layout, but that's another issue).
I tried to make this work by cloning my active cookbook repos into vendor/cookbooks and then pointing the Cheffile at them via :path => 'vendor/cookbooks/foo', but for some reason that copies the cookbook into the main cookbooks/ dir when you run librarian-chef install. Why is that? Knife then operates on that cookbook rather than the one in vendor/cookbooks and changes would need to be manually kept in sync with the git working copy. So that's a dead end.
The ideal scenario would be if librarian-chef could give me a cloned git repo from which I can push and pull (and properly isolate it from the parent repo in which it is operating, via submodules or something else), which is also in knife's cookbook path. Bonus points if it can do that from the :git => ... option rather than :path => ...
If there's a way to easily do this that I'm missing, I'd love to hear about it.
Thanks chefs!
Wes
|