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
|