Under what circumstances will Ruby $ LOAD_PATH be obtained from the parent process?

Question

In my cucumber scripts, if I call rake db:schema:load in the target folder of the Rails application, I get the cucumber process $ LOAD_PATH, and not my own Gemfile / load Rails path. I think this is very strange.

As a result, I get the following error:

 no such file to load -- rails/all 

I can not reproduce it outside my cucumber script.

 ruby -rubygems -e "system 'rake -T'" 

works fine → "rake -T" has its own application based on Gemfile $ LOAD_PATH; and does not generate the error above.

Can someone think why the child process ( rake -T or rake db:schema:load or rails runner... ; is called using system , exec , %x[...] or backtick; will start with the parent processes $ LOAD_PATH (from the Gemfile cucumber script) instead of your own $ LOAD_PATH (from the Gemfile Rails)?

Answer 1

When you use bundler, either through bundle exec or require 'bundler/setup' , it finds your Gemfile and then puts its location in ENV["BUNDLE_GEMFILE"] . However, if it is already installed, then the package simply reuses the value. This is what makes your Rails application use the Gemfile of the cucumber process.

If you want to do something in the context of another Gemfile, first clear ENV["BUNDLE_GEMFILE"] . Bundler provides the Bundler.with_clean_env(&blk) method, which may be useful; it executes its block with the environment, as it was before the Bundler boot. Of course, you can also clean it manually using something like system("env -u BUNDLE_GEMFILE rake sometask") .

Answer 2

The process generating environment ( ENV ) is transferred to the sub-shell. Or the cucumber itself, as you use the cucumber (for example, bundle exec cucumber ), your scripts or the code downloaded by the script (for example, the application and, therefore, the bundle), mess with your ENV . Environment variables such as RUBYLIB , GEM_PATH and BUNDLE_GEMFILE can significantly affect the way your sub-Ruby processes can load / run.

Try printing the ENV variable in your script and compare it with what you get when you do this with ruby -rubygems -rpp -e "pp ENV" or just ENV on the command line.

For what it's worth, a possible alternative would be to load and call the rake task directly, for example, Rake::Task['db:schema:load'].invoke , without using a sub-shell. However, it depends on what you are trying to do.