Things like travis will set BUNDLE_GEMFILE but the user may not bundle install or bundle exec so we can't rely on that as a test to see if we're in bundler.
We rely on eval "$(/opt/chefdk/bin/chef shell-init bash)" to clean up the rvm environment in travis.
GEM_PATH + GEM_HOME are set by rvm and must be cleaned in order to run the shell-init command
after shell-init is run GEM_PATH + GEM_HOME are set pointing at chefdk + the .chefdk dir
The workflow that we would have to support is:
use rvm and create an empty gemset
eval "$(/opt/chefdk/bin/chef shell-init bash)" and reset the env vars <-- this relies on the binstubs to reset the env to even invoke the chef command.
/opt/chefdk/embedded/bin/chef --version should work
Note that what people do is call embedded directly, that's not a typo there, so it bypasses the binstubs and just uses chefdk as a normal ruby.
So the problems with this are very annoying:
Things like travis will set BUNDLE_GEMFILE but the user may not
bundle installorbundle execso we can't rely on that as a test to see if we're in bundler.We rely on
eval "$(/opt/chefdk/bin/chef shell-init bash)"to clean up the rvm environment in travis.The workflow that we would have to support is:
eval "$(/opt/chefdk/bin/chef shell-init bash)"and reset the env vars <-- this relies on the binstubs to reset the env to even invoke thechefcommand./opt/chefdk/embedded/bin/chef --versionshould workNote that what people do is call embedded directly, that's not a typo there, so it bypasses the binstubs and just uses chefdk as a normal ruby.