chef exec rspec not working

[jperry]

Hey guys,

I am using chefdk 0.2.0 and and trying to run rspec without resetting my shell using chef exec rspec but things are not working. I was told I had to update the chefspec gem using chef gem install chefspec due to a dependency on rspec3 but that did not fix the issue. Here is the latest out:

> chef exec rspec
/opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `exec': No such file or directory - rspec (Errno::ENOENT)
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/base.rb:57:in `run_with_default_options'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/cli.rb:66:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/bin/chef:25:in `<top (required)>'
    from /usr/bin/chef:41:in `load'
    from /usr/bin/chef:41:in `<main>'

The workaround at the moment is to run eval "$(chef shell-init SHELL_NAME)" and then you can run rspec directly.

[danielsdeleo]

Can you run the following commands to give us more info?

chef exec env (I'm mostly interested in PATH, but GEM_ROOT, GEM_HOME, and GEM_PATH might be interesting, too. Make sure to scrub this if you set AWS credentials or anything like that in your environment)

chef exec which rspec

chef exec 'rspec -v' (you need the quotes or else chefdk will intercept the -v and print its own version).

chef exec gem which rspec

These are all working for me locally but on a slightly different version.

[jperry]

> chef exec env
GEM_ROOT="/opt/chefdk/embedded/lib/ruby/gems/2.1.0"
GEM_HOME=/opt/chefdk/embedded/lib/ruby/gems/2.1.0
GEM_PATH=/Users/jperry/.chefdk/gem/ruby/2.1.0:/opt/chefdk/embedded/lib/ruby/gems/2.1.0
PATH=/opt/chefdk/bin:/Users/jperry/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/packer

> chef exec which rspec
/opt/chefdk/embedded/bin/rspec

> chef exec 'rspec -v'
/opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `exec': No such file or directory - rspec (Errno::ENOENT)
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/base.rb:57:in `run_with_default_options'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/cli.rb:66:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/bin/chef:25:in `<top (required)>'
    from /usr/bin/chef:41:in `load'
    from /usr/bin/chef:41:in `<main>'

> chef exec gem which rspec
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-3.0.0/lib/rspec.rb

[danielsdeleo]

I think I've got this figured out, should have a patch shortly. We're currently passing our desired environment directly to ruby's exec, like this: https://github.com/opscode/chef-dk/blob/384153920fe5dc16dce71076eb8fa13a2ab33442/lib/chef-dk/command/exec.rb#L27 From my tests, this seems to modify the environment of the child program but doesn't affect the PATH used to find and invoke the command. exec has a lot of different behaviors corresponding to which of the family of C functions it runs, so it's confusing to find the exact code path in the ruby source that this goes through, but on my machine, I was able to observe this behavior with:

SET_ENV = {"PATH" => "/opt/chefdk/embedded/bin"}
exec_1 = fork do

  exec(SET_ENV, %q{ruby -v})
end

Process.wait(exec_1)

exec_2 = fork do

  SET_ENV.each {|k,v| ENV[k] = v}
  exec(%q{ruby -v})
end

Process.wait(exec_2)

In the first case, I get the version of my system ruby, in the second case I get the omnibus ruby from ChefDK. So it should be easy enough to fix.

[jperry]

@danielsdeleo - thanks for the follow up and I too have run into some weird exec issues in the past. Glad you were able to reproduce. Let me know when the patch is ready and I'll give it a try.

[danielsdeleo]

@jperry fixed in master, but updating the chef-dk app without installing a full ChefDK package is a bit involved. If you want to try it right away, you can nuke /opt/chefdk/embedded/apps/chef-dk, and then git clone master into that directory which should work (but be prepared to trash everything and reinstall if you do this). Otherwise there should be a nightly build in a day or so that you can run.

[jperry]

Thanks. I'll check out one of the nightly builds.