with_bundled_env causes trouble if BUNDLE_APP_CONFIG was set

[jdelStrother]

Describe the bug

In an environment where BUNDLE_APP_CONFIG is set, one set of bundler settings are used to load puma, and then a different set of bundler settings are used when forking off workers. This causes, eg:

> bundle exec puma -C config.rb hello.ru
[3026] * Pruning Bundler environment
[3026] Puma starting in cluster mode...
[3026] * Puma version: 5.4.0 (ruby 2.7.3-p183) ("Super Flight")
[3026] *  Min threads: 0
[3026] *  Max threads: 5
[3026] *  Environment: development
[3026] *   Master PID: 3026
[3026] *      Workers: 2
[3026] *     Restarts: (✔) hot (✔) phased
[3026] * Listening on http://0.0.0.0:9292
[3026] Use Ctrl-C to stop
[3027] + Gemfile in context: /Users/jon/Developer/puma-env/Gemfile
[3028] + Gemfile in context: /Users/jon/Developer/puma-env/Gemfile
Could not find rake-13.0.6 in any of the sources
Could not find rake-13.0.6 in any of the sources
Run `bundle install` to install missing gems.
Run `bundle install` to install missing gems.
[3028] ! Unable to start worker
[3027] ! Unable to start worker
[3028] /Users/jon/.gem/ruby/2.7.0/gems/bundler-2.2.16/lib/bundler/setup.rb:17:in `exit'
[3027] /Users/jon/.gem/ruby/2.7.0/gems/bundler-2.2.16/lib/bundler/setup.rb:17:in `exit'
[3028] Early termination of worker
[3027] Early termination of worker

I ran into this in a docker project where the base ruby image sets BUNDLE_APP_CONFIG=/usr/local/bundle, but I also happened to have a local .bundle directory which I was using outside of docker.

Puma config:

workers 2
prune_bundler

bundle exec puma -C config.rb hello.ru

To Reproduce

There's a reproduction repo here - https://github.com/jdelStrother/puma-vs-bundler

export BUNDLE_APP_CONFIG=/dev/null
bundle install
bundle exec puma -C config.rb hello.ru

Perhaps Puma::Launcher#prune_bundler could be tweaked to something like:

    def prune_bundler
      return if ENV['PUMA_BUNDLER_PRUNED']
      return unless defined?(Bundler)
      require_rubygems_min_version!(Gem::Version.new("2.2"), "prune_bundler")
      unless puma_wild_location
        log "! Unable to prune Bundler environment, continuing"
        return
      end

      dirs = files_to_require_after_prune

      log '* Pruning Bundler environment'
      home = ENV['GEM_HOME']
      bundle_gemfile = Bundler.original_env['BUNDLE_GEMFILE']
+     bundle_app_config = Bundler.original_env['BUNDLE_APP_CONFIG']
      with_unbundled_env do
        ENV['GEM_HOME'] = home
        ENV['BUNDLE_GEMFILE'] = bundle_gemfile
+       ENV['BUNDLE_APP_CONFIG'] = bundle_app_config
        ENV['PUMA_BUNDLER_PRUNED'] = '1'
        args = [Gem.ruby, puma_wild_location, '-I', dirs.join(':')] + @original_argv
        # Ruby 2.0+ defaults to true which breaks socket activation
        args += [{:close_others => false}]
        Kernel.exec(*args)
      end
    end

?

Desktop

• OS: MacOS, & LinuxKit in Docker
• Puma Version: 5.4.0

[cjlarose]

Thanks for the detailed issue and the reproducible example!

This issue appears to be legitimate and the proposed changes to prune_bundler look appropriate to me.

If you're interested in opening a PR, I think TestPreserveBundlerEnv might be a good place to add a regression test for this behavior.

[jdelStrother]

Sure, will take a look