[chef-dev] Re: Re: Re: Re: RSpec in ChefDK

[Noah Kantrowitz < >]

As someone that also maintains a few RSpec helper libraries, I can say that 
making a "chefspec" binary would probably increase the support burden on Seth 
and the other folks that help out with ChefSpec. Questions like "How do I do 
X with ChefSpec?" are already pretty common, and 90% of the time the answer 
is "you don't, you do it with RSpec because ChefSpec is just a library". 
Mentally reinforcing this by making the user actually run `rspec` as the 
entry point gives the user a bit of context for asking questions (or using 
Google to look things up). I can't say those are Seth's reasons and would not 
presume to speak for him, but they sound good to me at least :-)

--Noah

On May 6, 2015, at 9:08 PM, Adam Jacob 
<
 >
 wrote:

> Yeah, not so much. We need to work with Seth to understand his concerns, 
> talk about what we need, and figure out what the right solution is for 
> everyone. 
> 
> Adam
> 
> On Wed, May 6, 2015 at 12:06 PM, Charles Johnson 
> <
 >
>  wrote:
> 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.
> 
>     --Charles
> 
> On May 6, 2015 at 11:55:42 AM, Daniel DeLeo 
> (
 )
>  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? 
>> > 
>> > --Noah 
>> 
>> 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. 
>> 
>> -- 
>> Daniel DeLeo 
>> 
>> 
>> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail