[chef] Re: Chef-DK Question

[Lamont Granquist < >]

chef-dk really does two things:

1.  bundles everything together (ruby, chef, berkshelf, TK, nokogiri, 
etc)
2.  also has the 'chef' workflow tool installed by the chefdk gem

we're also going to suggest for new users to let chefdk take over your 
system a little bit and you'll use that instead of your system ruby 
(and /opt/chefdk/embedded/bin will need to be in your path).  in that 
case you can bundle install tools into chefdk and use it in preference 
to your system ruby (ideally not having any system ruby installed at 
all).  that'll create some drift in the gems installed in chefdk, but 
at that point you should be check in Gemfile.lock files and bundle 
install/bundle exec'ing anyway.

but, if you've already solved this problem and don't need/want the 
packaging problem solved for you, then you can skip using the chefdk 
omnibus package that we ship entirely and instead use rvm/rbenv/chruby 
to manage your ruby installation and gem install / bundle install your 
tools like you have been doing.  then what you'll get out of the chefdk 
gem, is the chef command line tool, which is going to replace all the 
use cases from knife-spork, berks uploading, berks cookbook generators, 
berkflow, meez, etc, on top of integration with planned Chef 12/13 
features to make cookbook workflow easier.

however, there will also be some packaging things that you'll missing 
with chefdk like the 'appbundler' way that we package command line 
tools, which reduces start up cost considerably and makes knife and 
other command line ruby tools a lot more snappy.  we're also not going 
to be supporting debugging system rubies.  you're going to need to be 
able to get the same ruby version installed that we ship in the omnibus 
packages.  if you go the DIY route you'll be accepting self-support, 
and at a some point you may find it a lot easier just to install the 
chefdk packages (you may run into bugs closed 'wontfix - cannot 
replicate in chefdk omnibus packages').

On Sat May 31 02:39:25 2014, Torben Knerr wrote:
> Ohai chefs!
>
> Glad to see that Chef-DK brings together the most commly used tools in
> the chef community. Not only because they are now "officially
> recommended" but also for the reduced likelihood of dependency
> conflicts (think of the json gem). Sweet! :-)
>
> One thing I didn't fully understand though: How is it intended to work
> with different projects / cookbook repos that have different versions
> of chefspec, foodcritic, test-kitchen, etc?
>
> I probably can't / don't want to upgrade all my repos everytime a new
> version of Chef-DK comes out. Is this coupling intended? The fact that
> it bundles chefspec, foodcritic and test-kitchen makes it look like so...
>
> From my experience with bills kitchen [0] ("all you need for cooking
> with Chef on windows" - think of it as a more opinionated,
> windows-only Chef-DK++) I went down the same path:
>
> First I bundled not only Chef and Vagrant but also pre-installed loads
> of related gems in a configuration that would not conflict with each
> other.
>
> This got more and more painful every time a new version of one of the
> gems (e.g. chefspec) came out. Upgrading the gem was a global
> operation and thus affected all projects I was working with.
>
> Since this was way too annoying I switched to another approach [1]:
> 1. bills kitchen now only bundles Ruby (+DevKit), Chef and Vagrant
> 2. bundler is the only pre-installed gem
> 3. bindler [2] is the only pre-insalled vagrant plugin
>
> All other gems (like berkshelf, chefspec, foodcritic, test-kitchen,
> etc) and vagrant plugins (like vagrant-omnibus, vagrant-berkshelf,
> etc) are now managed per project in a Gemfile or plugins.json
> respectively.
>
> Having the core tools decoupled from the other gems gave me a great
> deal of flexibility. I can now work on older projects as well as newer
> projects using the same version of bills kitchen, and I'm no longer
> forced to upgrade older projects just because of a newer version of
> bills kitchen.
>
>
> Right now it seems to me that Chef-DK follows the approach to bundle
> everything. Sure, you can still use Gemfiles in your projects, but
> wouldn't this end up in confusion due to the different Ruby
> installation (System ruby vs. Chef-DK embedded ruby)?
>
> What's the intended usage of Chef-DK here?
>
>
> Cheers,
> Torben
>
> [0] https://github.com/tknerr/bills-kitchen
> [1] compare
> https://github.com/tknerr/bills-kitchen/blob/0.10/README.md with master
> [2] https://github.com/fgrehm/bindler