[chef] Re: Re: Better workflow for actively-developed cookbooks

[Kevin Karwaski < >]

Hey Wes,

There was a great conversation related to Librarian-Chef earlier in April:

http://lists.opscode.com/sympa/arc/chef/2012-04/msg00326.html

Not sure if this is useful for you but hope it helps!

Cheers,
-K.

On Fri, Jun 22, 2012 at 1:24 PM, Wes Morgan 
<
 >
 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 
> <
 >
>  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
>
>
>



-- 
Kevin Karwaski