1) Native gems: i use linux as my laptop(ubuntu 14.04), rest of team uses OSX. integration tests are also on lxc (in CI), out side CI both lxc & vagrant is used. lxc deps are linux specific, which we address using separate Gemfile or groups inside a Gemfile. all these details are captured in git. I dont know how i'll address that with ChefDK.
2) ChefDk being a system installer will require any installation script (provisioning developer machine for example) to have root privilege for execution. Currently its same as any other ruby project (bundle install). all our Gemfiles(s) have locked ruby versions (that reflect production) and I dont enforce any constrain on what ruby version manager developers should use.
3) When we hit any bug in our chef tooling ( chefspec, berks, chef itself), Gemfiles allows us to test and fix those bugs against our patches. All of this is captured in out feature branches in our repo (which revert back the Gemfile to point to GA releases). This will be very complicated with chefdk (where we'll capture the gem versions of chefdk?).
4) lot of our dependency cookbooks (e.g. heavywaters, lusis' etc) uses librarian. I still use berks., but I am keen to get rid of celluloid from non-jruby apps. And if that happens I have to modify chefdk.
5) if rvm is installed, then GEM_PATH, and GEM_HOME cant screw with any ruby scripts, even if it has hardcoded exact omnibus ruby path. i had hit this with chef-omnibus. the only bulletproof way to address this was to invoke ruby scripts with env -i (i dont know of any better solution :-( ). till recently chef had a bug (PATH) which would inhibit invoking env -i chef-client , but now thats fixed. So even with all other system rubies i can now invoke any ruby script (including chef) with env -i , as long as it has a valid ruby in its #! line. With this, gem management is now really trivial and decoupled (use a shared gemset or have local .bundle & Bundler.setup as part of the scripts). this reduces the incentive to use chefdk (in fact any omnibus installation)
6) Chef (11.8) is already available on ubuntu 14.04 , with ruby 1.9 & 2.0. So we can do a mixmode with system wide ruby+chef from apt repo, and individual scripts having their own stuff. ruby tooling has changed a lot on ubuntu, its not like 2 years back when we all were stuck with 1.8.7 even if 1.9 was out.
7) after vagrant went omnibus, i had to rewrite lot of scripts only because vagrant's plugin model was changed. I fear what will happen if chefdk introduces something like that,
these are some of the immediate concern i have, and i think im not the intended user here (correct me if im wrong),
But i do understand that building berks is time consuming now (16 min on my laptop), and might be more difficult on windows. ChefDK will definitely shine there. In fact anyone, who wants to use a single version of chef for really long time will be better off with chefdk.