brittle handling of ENV['BUNDLE_GEMFILE']

[e2]

Setting BUNDLE_GEMFILE= (as opposed to unsetting the env variable) causes Bundler to go crazy.

The problem is with these 2 lines here: https://github.com/bundler/bundler/blob/e8c962ef2a3215cdc6fd411b6724f091a16793d6/lib/bundler/cli.rb#L19-L20

When BUNDLE_GEMFILE happens to be "":

1. custom_gemfile becomes "", which evaluates to true
2. File.expand_path(custom_gemfile) expands to the current directory and ...
3. ENV['BUNDLE_GEMFILE'] now contains a directory instead of a file - which causes Bundler to blow up.

Use case: I'm running bundle install as root on one Gemfile, and then running another, unrelated bundle install on another Gemfile - the variable is set and propagated and deleting the env variable is tricky on my setup (my workaround is: /usr/bin/env -u BUNDLE_GEMFILE foo, which isn't portable).

[indirect]

You're right, and this is a bug. We should fix it. The reason no one else has had this problem, though, is that Bundler provides a way to run commands outside of the current bundle:

Bundler.with_clean_env do
  `cd /other/bundle && bundle install`
end

I'd suggest that as a workaround for now.

[e2]

Ideally, I'd be able to do: BUNDLE_ENV=clean foo or RUBYOPT=-rbundler/clean foo

In my case, I have my hands tied on "both sides" (root and user), because I can't call Ruby code from root context (I don't have access, though process is run through bundle exec as root - which is why the variables are exported) and I can't use Bundler from user's Ruby (because RVM may not be installed yet).

[agis]

@indirect Couldn't we just append an additional !custom_gemfile.empty? check in here?

[indirect]

That sounds good to me.

[agis]

Cool, will wrap up a PR with some tests soon.

[e2]

Cool, thanks!