[[chef-dev]] Re: [[chef-dev]] Re: [chef] Re: Re: Contributing to Cookbooks (was chef & hoptoad)

[Chad Woolley < >]

On Fri, Jul 16, 2010 at 5:47 PM, Alex Soto 
<
 >
 wrote:
>> Currently knife only supports the Opscode cookbooks site, since it 
>> provides an API that we can use directly. I do not knife if the dev team 
>> has plans to implement support for other sites or methods by which to 
>> 'vendor' cookbooks. The advantage of the Opscode site vs say GitHub is 
>> that it integrates well with the Platform, and its a better known quantity 
>> for the API usage. But I'll let Adam or Dan speak up about potential 
>> roadmap topics in that regard.
> I looked at the code, and I see what you mean, but it seems like it's just 
> pulling down a tarball.  By pointing to another repo and using git archive, 
> you can mimic that behavior.  Unfortunately, it doesn't seem that github 
> allows using that command to pull a single cookbook as a tarball so it may 
> not be useful for github, but private github repo's work that way.

Yes, that's exactly what I would like to see- a parallel mode for
knife which works with a plain git repo, or even just github.  This
would allow people who don't use chef-server to still fork and
participate in the opscode cookbook community.

When I first started with chef, I tried briefly to be a good citizen
and do this manually fork opscodes' cookbooks using git topic branches
and do pull requests, tickets, etc.  However, it's just too much work
(i.e. much easier to just write all my cookbooks from scratch using
opscode's cookbooks as an example, and not fork opscode's cookbooks or
contribute anything back).

Since my from-scratch cookbooks were so much simpler, focused, and
non-buggy; I'm not sure I would fork opscode's again even if it were
easy to contribute back, but that's a discussion for another day ;)
chef-solo and ohai are the bomb in any case, thanks a lot for them.

-- Chad