[chef] Re: Re: ChefDK and collaborating with others

[AJ Christensen < >]

yo,

On Fri, Dec 19, 2014 at 10:13 AM, David Petzel 
<
 >
 wrote:
> For what its worth, I share your confusion here. We've historically used the
> Gemfile approach as well and as we transition to ChefDK, I still feels like
> we need this... As very simplistic example we use rubocop to enforce rules
> (build fails if there are offenses). Since new version introduce new rules
> folks with varying levels of the gem and/chefDK get different results. It's
> unclear to me how ChefDK (which as I understand, suggests you can do away
> with Gemfiles) solves this issue?
>
>
>
> On Thu, Dec 18, 2014 at 3:58 PM, Hajducko, Steven
> <
 >
>  wrote:
>>
>> I'm somewhat new to Chef and Ruby in general, so please bear with me ( and
>> feel free to correct any misguided statements! )
>>
>>
>> From what I understand, pre-ChefDK, people would use bundler to pin the
>> gem versions they used to develop/test their application/cookbook.  I slap
>> it all into a Gemfile, bundle install, commit the Gemfile.lock.  You
>> download my repo, you bundle install and you immediately have all the same
>> gem versions that I used.
>>
>>
>> My confusion stems with how this is supposed to work with ChefDK.  Suppose
>> that I use ChefDK to create my cookbook, do all my development and testing
>> and release it to a public repo.  My colleague, however, doesn't have 
>> ChefDK
>> and grabs my repo.  How is he supposed to know what gems I used?  My first
>> answer would be - I either document it in the README or I just say 'Install
>> ChefDK v0.3.5'.  Another option would be to manually create a Gemfile for
>> everything that I used out of ChefDK and include that along with my repo?
>> But in both cases, I'm having to keep some extra piece of information up to
>> date with everything I'm using out of ChefDK ( or just telling him he 
>> better
>> install it ).  Am I missing something there?
>>
>>
>> The second scenario I'm hazy about is when you get into the situation when
>> we start drifting between ChefDK versions.  Perhaps I haven't upgraded my
>> ChefDK for awhile and you're on the latest and greatest.  What's keeping us
>> in sync, so that we're using the same versions of Test Kitchen, ChefSpec,
>> etc?  Or does it not matter, because in general, the differences between 
>> the
>> gems provided in different ChefDK versions isn't a big enough concern?
>>
>>
>> I understand ( I think ), that if I start using 3rd party gems that aren't
>> included in ChefDK, I should be bundle installing them and including the
>> Gemfile.  I think it's the two scenarios above that I'm unsure about and 
>> I'm
>> curious how others are doing this.
>>
>>
>> I've read a few blog posts and the previous mail on the list
>> http://lists.opscode.com/sympa/arc/chef/2014-06/msg00000.html, but I think
>> I'm still confused enough what the vision/workflow is that I had to ask.
>>

yo,

ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks' Gemfiles, or even mega repository
Gemfiles. I don't think I've heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.

One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.

I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn't take an hour to
compile on smaller rigs :-)

I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.

hope this helps~

cheers,

--aj

>>
>> Thanks,
>>
>>
>> --
>>
>> sh
>>
>>
>