RSpec in ChefDK


#1

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


#2

I noticed this as well.

Our current solution is to ensure that people using rspec that comes with
omnibus is to have their Ruby environment set to use the ChefDK-supplied
one, typically by recommending the addition of the profile-loader line, as
recommended by ChefDK’s installer:

eval "$(chef shell-init bash)"

In ~/.profile or such.

Is this perfect? Nope. But it works.

For people that hack on Ruby and are more comfortable with environment
mutation (like myself), we leave the env setup to them.

But for most of our team, the env setup is the way to go.

-M

On Wed, May 6, 2015 at 2:40 PM, Noah Kantrowitz noah@coderanger.net 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


#3

Feels like an obvious patch to me.

Adam

On Wed, May 6, 2015 at 11:46 AM, Mike miketheman@gmail.com wrote:

I noticed this as well.

Our current solution is to ensure that people using rspec that comes with
omnibus is to have their Ruby environment set to use the ChefDK-supplied
one, typically by recommending the addition of the profile-loader line, as
recommended by ChefDK’s installer:

eval "$(chef shell-init bash)"

In ~/.profile or such.

Is this perfect? Nope. But it works.

For people that hack on Ruby and are more comfortable with environment
mutation (like myself), we leave the env setup to them.

But for most of our team, the env setup is the way to go.

-M

On Wed, May 6, 2015 at 2:40 PM, Noah Kantrowitz noah@coderanger.net
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


#4

shell-init bash adds both the bin/ and embedded/bin/ dirs to the path, but on Windows only bin/ gets added by the MSI installer :frowning: Maybe for ChefDK 1.0 we should consider removing embedded/bin/ from the shell-init generated PATH so it stays internal-only? Also related, the “user_dir” in $HOME/.chefdk/etcetc doesn’t get added to the PATH on Windows but it does with shell-init.

–Noah

On May 6, 2015, at 8:46 PM, Mike miketheman@gmail.com wrote:

I noticed this as well.

Our current solution is to ensure that people using rspec that comes with omnibus is to have their Ruby environment set to use the ChefDK-supplied one, typically by recommending the addition of the profile-loader line, as recommended by ChefDK’s installer:

eval "$(chef shell-init bash)"

In ~/.profile or such.

Is this perfect? Nope. But it works.

For people that hack on Ruby and are more comfortable with environment mutation (like myself), we leave the env setup to them.

But for most of our team, the env setup is the way to go.

-M

On Wed, May 6, 2015 at 2:40 PM, Noah Kantrowitz noah@coderanger.net 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


#5

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


#6

On May 6, 2015, at 8:55 PM, Daniel DeLeo dan@kallistec.com 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.

The appbundler perf boost is nice, but having it linked even without that would at least be a better UX than “command not found” :slight_smile: Granted the platform most likely to hit this is Windows, which is precisely where the perf boost is most needed.

–Noah


#7

See also https://github.com/chef/chef-dk/issues/18

On Wed, May 6, 2015 at 2:00 PM, Noah Kantrowitz noah@coderanger.net wrote:

On May 6, 2015, at 8:55 PM, Daniel DeLeo dan@kallistec.com 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.

The appbundler perf boost is nice, but having it linked even without that
would at least be a better UX than “command not found” :slight_smile: Granted the
platform most likely to hit this is Windows, which is precisely where the
perf boost is most needed.

–Noah


Nathan L Smith
smith@chef.io


#8

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 (dan@kallistec.com) 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


#9

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 charles@chef.io 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 (dan@kallistec.com) 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


#10

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 :slight_smile:

–Noah

On May 6, 2015, at 9:08 PM, Adam Jacob adam@chef.io 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 charles@chef.io 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 (dan@kallistec.com) 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