>@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.

Correct, it's always possible for someone running Windows wanting to be able to test a cookbook, but as this cookbook is not designed for Windows I don't see the point of this comment.

>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.

We should make test-kitchen as easy as possible for developers to test in the pattern they want.  That being we should not create additional steps in order to deviate from the accepted *normal*.

> Using .kitchen.local.yml is an extra step, but I am guessing as Vagrant is fairly popular for most Ruby developers it was easy to be short sighted and create a format that is only designed for Vagrant.

I imagine it's saying, hey Mr. Developer, I understand you use Vagrant and that's fine.  Once you outgrow it I'll be there to help you with Rackspace, EC2, LXC, or Openstack if you want to enable those drivers.  

* ec2 uses fog, which should work on Windows.
* rackspace I imagine does as well
* lxc uses lxc-awesome-ephemeral which is only a shell script wrapped around a Rubygem.  Technically this could work on Windows if it supported LXC or a container mechanism the shell script could interact with.

>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 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.

Is there a particular reason? or is this a knee jerk reaction to everyone uses Vagrant so let's just keep that as the default?