Replying to myself since I did t subscribe with my new email ;)
On Jun 1, 2014 12:51 PM, "Adam Jacob" <
">
> wrote:
>
> To clarify here, because there is some confusion happening on twitter:
>
> The Chef DK is a supported (by Chef Software Inc) bundle of tooling, intended to make things easier for people developing with Chef. We are taking on the burden of vetting the tools, supporting them, upgrading them, and working with the upstream maintainers as part of their communities to ensure a smooth experience. As a business, we will extend our support of our customers to cover everything that ships in the DK.
>
> Lamont wasn't being clear here when he talks about bugs - we are going to support and focus our efforts on the packages we ship (just like we do for the client and server). Bugs and bug fixes for other platforms are perfectly great. There is every intention to make supporting more and more platforms officially as part of the process easy, which will expand the set we (as a company) vet.
>
> Nobody is going to get abandoned, the Chef gem will continue to be released and maintained, and folks can do as they will.
>
> As noah pointed out on twitter, we will have a ruby version policy for Chef. I nominated 1.9.3 and up.
>
> Adam
>
> Adam
>
> On May 31, 2014 12:12 PM, "Lamont Granquist" <
">
> wrote:
>>
>> 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
>>
>>
>>
Archive powered by MHonArc 2.6.16.