The appbundler perf boost is nice, but having it linked even without that would at least be a better UX than "command not found" :-) Granted the platform most likely to hit this is Windows, which is precisely where the perf boost is most needed.
On May 6, 2015, at 8:55 PM, 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.
>
--Noah
Archive powered by MHonArc 2.6.16.