[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Berkshelf Frustrations, or, Am I Just Doing It Wrong?

[Brian Akins < >]

In the actual chef orgs, it really just a convenience for downloading cookbooks from our cookbook org and uploading them to a particular chef server/org. We could just write a tool to do this, I suppose, but we already use berkshelf with Vagrant for testing, etc already. When building/updating out TLC's we can use berkshelf to generate the list of exact versions we depend on.  If Berksfile.lock worked as intended, then we wouldn't have to do this I suppose.

On Fri, Mar 29, 2013 at 1:50 PM, nick hatch < " target="_blank"> > wrote:

Maybe I'm just being dense -- but what value does Berkshelf provide if you explicitly pin versions in this manner? 

-n

On Thu, Mar 28, 2013 at 1:57 PM, Jamie Winsor < " target="_blank"> > wrote:
> Michael's explanation is 100% in line with how we handle things here at Riot
>
> --
> Jamie Winsor
> @resetexistence
> https://github.com/reset
>
> On Thursday, March 28, 2013 at 1:07 PM, Michael Glenney wrote:
>
> We pin versions in the top level cookbooks.  We also restrict versions in
> our environment files but it's always a =< so if an older cookbook is
> relying on an older version of something the environment file doesn't get in
> the way.
>
> In the metadata of top level cookbooks we're strict:  depends "java", "=
> 1.0.0"
> and we list out even cookbooks that aren't called directly by the TLC, that
> are dependencies of others, just to make sure everything is pinned.
>
> In the non-TLC's we're more relaxed:  depends "java", "~> 1.0.0"
> which makes development and testing a little more bearable.
>
> MG
>