BUNDLE_WITHOUT environment variable is lower priority than .bundle/config

[mheap]

Describe the problem as clearly as you can

The BUNDLE_WITHOUT environment variable is lower priority than a cached value in .bundle/config, leading to unexpected behaviour.

Post steps to reproduce the problem

# ruby via rbenv
❯ ruby --version
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20]
❯ bundle --version
Bundler version 2.2.25

Given the following Gemfile:

source "https://rubygems.org"

group :test, :development do
    gem "rspec"
end

I run BUNDLE_WITHOUT="test" bundle install which still installs rspec as I forgot to specify BUNDLE_WITHOUT=test:development

So, I update my command to exclude both of those groups, but the gems are still installed:

❯ BUNDLE_WITHOUT="test:development" bundle install
Using bundler 2.2.25
Using diff-lcs 1.4.4
Using rspec-support 3.10.2
Using rspec-core 3.10.1
Using rspec-expectations 3.10.1
Using rspec-mocks 3.10.2
Using rspec 3.10.0
Bundle complete! 1 Gemfile dependency, 7 gems now installed.
Gems in the group 'test' were not installed.
Bundled gems are installed into `./vendor/bundle`

The issue here is that BUNDLE_WITHOUT was cached after my first run in .bundle/config:

❯ cat .bundle/config
---
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "test"

The solution is to remove the BUNDLE_WITHOUT line in .bundle/config and re-run your command.

Which command did you run?

BUNDLE_WITHOUT="test" bundle install
BUNDLE_WITHOUT="test:development" bundle install

What were you expecting to happen?

Bundler would exclude both groups on the second run

What actually happened?

❯ BUNDLE_WITHOUT="test:development" bundle install
Using bundler 2.2.25
Using diff-lcs 1.4.4
Using rspec-support 3.10.2
Using rspec-core 3.10.1
Using rspec-expectations 3.10.1
Using rspec-mocks 3.10.2
Using rspec 3.10.0
Bundle complete! 1 Gemfile dependency, 7 gems now installed.
Gems in the group 'test' were not installed.
Bundled gems are installed into `./vendor/bundle`

If not included with the output of your command, run bundle env and paste the output below

Environment

Bundler       2.2.25
  Platforms   ruby, x86_64-darwin-20
Ruby          2.7.2p137 (2020-10-01 revision 5445e0435260b449decf2ac16f9d09bae3cafe72) [x86_64-darwin20]
  Full Path   /Users/michael/.rbenv/versions/2.7.2/bin/ruby
  Config Dir  /Users/michael/.rbenv/versions/2.7.2/etc
RubyGems      3.1.4
  Gem Home    /Users/michael/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0
  Gem Path    /Users/michael/.gem/ruby/2.7.0:/Users/michael/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0
  User Home   /Users/michael
  User Path   /Users/michael/.gem/ruby/2.7.0
  Bin Dir     /Users/michael/.rbenv/versions/2.7.2/bin
Tools         
  Git         2.30.1 (Apple Git-130)
  RVM         not installed
  rbenv       rbenv 1.1.2
  chruby      not installed

Bundler Build Metadata

Built At          2021-07-30
Git SHA           7f0f257c7a
Released Version  true

Bundler settings

path
  Set for your local app (/private/tmp/til/.bundle/config): "vendor/bundle"
without
  Set for your local app (/private/tmp/til/.bundle/config): [:development]

Gemfile

Gemfile

source "https://rubygems.org"

group :test, :development do
    gem "rspec"
end

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    diff-lcs (1.4.4)
    rspec (3.10.0)
      rspec-core (~> 3.10.0)
      rspec-expectations (~> 3.10.0)
      rspec-mocks (~> 3.10.0)
    rspec-core (3.10.1)
      rspec-support (~> 3.10.0)
    rspec-expectations (3.10.1)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.10.0)
    rspec-mocks (3.10.2)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.10.0)
    rspec-support (3.10.2)

PLATFORMS
  x86_64-darwin-20

DEPENDENCIES
  rspec

BUNDLED WITH
   2.2.25

[deivid-rodriguez]

In general, this is expected, bundler's config loading priority is first local config, then ENV, then global config. See https://bundler.io/v2.2/man/bundle-config.1.html.

The bug here is that passing BUNDLE_WITHOUT is silently caching the option as local configuration, creating this unexpected behaviour.

The story of that bug is pretty convoluted, but it's clear that it needs to be fixed as soon as possible, since we have received at least two recent reports about it.

It was initially fixed by #3666, but then I reverted the fix at #4154, because it turned out it was some kind of workaround to the fact that bundle config saves without and similar configurations globally rather than locally by default, and it was creating issues for some people relying on it. I think the workaround was meant for migrating global configurations at ~/.bundle/config to be local, but it was affecting also ENV (your case).

If we make bundle config local by default, the original bug fix should no longer create any of those issues, so it can be restored. There's a chance of creating some other kind of incompatibility for someone relying on all these bugs, but I'll do the right thing anyways:

• I'll make bundle config save configuration locally by default.
• Then I'll restore the bug fix to not copy ENV and global configuration to local configuration by default.