- From: Jeff Blaine <
>
- To:
- Subject: [chef] Re: Re: Re: An deep topic
- Date: Tue, 08 Jul 2014 19:46:09 -0400
On 7/8/2014 1:09 AM, John E. Vincent (lusis) wrote:
>
Julian,
>
>
Thanks for taking the time to respond and also thanks for the feedback
>
on the twitters. More inline.
>
>
Do I believe that we ingested too much? Yes, the #1 pain point people
>
had with Chef was client-side dependency resolution. We grabbed
>
Berkshelf, the first thing that was convenient & met the need. But we
>
also got a lot of things that are kind of superfluous to the goal. The
>
"Berkshelf Way", "Environment Cookbooks", and friends all have little
>
to do with that, and will not be used by most people. (Bring on the
>
flames?)
>
>
>
I think this is accurate and communicates where I have a problem. All
>
the things have been intermingled when all that was needed was a
>
depsolver.
Enormous +1 from me. We've no interest in implementing the Berkshelf Way
and have no desire for Librarian or Berkshelf as they stand. The
benefits of a cookbook depsolver are obvious, and I completely
understand how the tooling needs to mature via things like that, but
we've never had a real need for even that.
>
Client-side dependency resolution is what it solves, in other words,
>
the need to get into dependency downloading hell ("knife cookbook
>
download xyz", oh noes, "xyz" depends on these other 3 cookbooks that
>
depend on 2 other ones that depend on...)
>
>
>
I guess this was where I didn't have a problem. My deps always resolved
>
fine with "knife cookbook site vendor" and I never had a problem. I look
>
now and see that maybe I was stuck in some old deprecated way but muscle
>
memory is a thing. But it always did what I wanted ;)
Exactly. Get out of my brain.
--
Jeff Blaine
kickflop.net
PGP/GnuPG Key ID: 0x0C8EDD02
Archive powered by MHonArc 2.6.16.