CHEF is taking on the paid support burden for chefspec in the chefdk context. As such we should optimize the chefdk experience around the user first, and the desires of the upstream maintainer second.
On May 6, 2015 at 11:55:42 AM, Daniel DeLeo (firstname.lastname@example.org) wrote:
On Wednesday, May 6, 2015 at 11:40 AM, Noah Kantrowitz wrote:
Was just working on some slides about ChefDK and noticed that rspec looks like it is still only in the embedded/bin directory, meaning you need to
chef exec rspec. Most other top-level tools like berks and rubocop are linked in the main bin/ directory so they are available directly, any reason to not do this for rspec?
For rspec, I think the relevant Chef-specific user-facing use case is ChefSpec. The contention there is whether we want to make ChefDK’s rspec ChefSpec-specific, which means it locks Chef Client and deps to a specific version which would give you the performance boost from appbundler, but would probably not be what you want for “generic” rspec usage. We could make a
chefspec executable that we appbundle, but Seth Vargo doesn’t want this and he’s the creator/maintainer of ChefSpec so I’m hesitant to go against that, but on the other hand it seems like the most pragmatic option.