@fujin @damm runit does not work on Windows, but this is for *development* - Chef does nothing with the Gemfile on the server; and it's totally possible that someone is using Windows for development.

By your logic, we should just include `kitchen-*` from RubyGems, which I believe is flawed. If the cookbook does not require kitchen-lxc to run (for example), it should not be included in the Gemfile. Because @fnichol did a lot of work with TK around bundling and unbundling, there's nothing stopping you from having kitchen-lxc installed and using the LXC driver locally. However, for the "average" user, I don't think we should be including all these extra drivers. The drivers don't have to be in the Gemfile to be used. 

It's like telling a new developer: not only do you need Ruby, need to know about RubyGems, need to know about bundler, and the whole Ruby universe - but also you need to spin up a remote instance to run your tests via LXC and EC2. The `kitchen.yml` doesn't even work with those drivers - you need to create a custom `kitchen.local.yml` with all those credentials. It's yet another thing we require of the end user.

I fundamentally disagree that having those in the Gemfile is "harmless". Furthermore, to the best of my knowledge, we do not include other kitchen drivers in other Opscode cookbooks. I'd be curious to see what @jtimberman says, but I don't think we should just stick with the "basic" test kitchen configuration - which is `kitchen-vagrant`. There's nothing stopping you from using kitchen-ec2 or kitchen-lxc in your local development toolchain. It's unnecessary to add them to the Gemfile.