Respect Gemfile bundler setting in Bundler.setup

[godfat]

When we run bundle exec it'll look at Bundler.settings[:gemfile]
and respect the Gemfile setting. However, when we just require
bundler/setup or run Bundle.setup, it'll not look through that.

This should make this behaviour consistent.

More details can be found at:
https://gitlab.com/gitlab-org/gitlab/-/issues/339939#note_667461354

What was the end-user or developer problem that led to this PR?

Try the following scenario:

• bundler config set --local gemfile Something
• Put something in Something but not Gemfile
• Notice that bundle exec will look for Something as expected, but ruby -rbundler/setup will not

What is your fix for the problem, implemented in this PR?

I found in bundler/lib/bundler/cli.rb there's a snippet:

custom_gemfile = options[:gemfile] || Bundler.settings[:gemfile]
if custom_gemfile && !custom_gemfile.empty?
  Bundler::SharedHelpers.set_env "BUNDLE_GEMFILE", File.expand_path(custom_gemfile)
  Bundler.reset_settings_and_root!
end

This does not run when we run Bundler.setup causing this inconsistency.

In order to fix it, make sure we also run this in Bundler.setup.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

Hei @godfat, this is great!

I was actually aware of this issue and I was trying a different approach at #3963 to fix it.

The approach here is not as correct because it requires to "re-resolve" settings (that Bundler.reset_settings_and_root!). So settings used at bundler load time will be picked up from the default location, while settings used after "re-resolving" settings will use the new location. With the approach in #3963, all settings are read from the correct location from the beginning. For the same reason, the approach in #3963 has no overhead on bundler/setup performance, although I think the time to do this should be negligible.

However, the --gemfile flag already has the same "problem" and has not really resulted in any issues that I know of. And also #3963 is quite tricky and could potentially break things in some edge cases.

So, I'm not fully sure, but I tend to think we should go with the approach in here first, and then consider #3963 later.

[godfat]

@deivid-rodriguez Oh! I see where this was coming from now. Thank you for the context. The thing I was missing was that I didn't know the config path can actually be based on where Gemfile is located.

I think this is problematic given how the configuration setting is designed right now. Like you mentioned, this is chicken-and-egg and it's impossible to be perfectly resolved if we keep it that way.

I personally think that ideally the config path should be configurable via something like BUNDLE_CONFIG, and that can point to actual Gemfile and we should not allow using BUNDLE_GEMFILE to locate BUNDLE_CONFIG because it's very confusing and again making chicken-and-egg issue.

It seems like we can actually do that with BUNDLE_APP_CONFIG? In that case we should probably just deprecate BUNDLE_GEMFILE, or deprecate that config path can be found by Gemfile. If we can ever afford that.

I suppose that's also what you're trying to do with #3963, excuse me I didn't read through all the changes carefully.

Bundler is so crucial to many projects, and given how complex it is right now, any compatibility related changes can cause huge issues. I'll be honest I wasn't really happy when bundler broke the setup from time to time, so I can fully understand that we should not introduce any breakage, and everything will have to be backward compatible.

So perhaps my question is, can you foresee this pull request might introduce any incompatibility, even when it should be fixing some consistency issue? If no, I would highly hope this can be merged first, and would be nice to be back porting it as well.

There's a failure: https://github.com/rubygems/rubygems/runs/3496250763

This was with ruby-2.6, rgv-3.0, and I would try to look into it. It's likely I have to install the exact same version to reproduce it. It's late here and I'll try to look into it tomorrow or next week. In the mean time, any pointers will be appreciated 🙏