ruby.git/lib/bundler/environment_preserver.rb, branch v4.0.4

[ruby/rubygems] Add support for BUNDLE_LOCKFILE environment variable

2025-11-20T23:01:03+00:00

This specifies the lockfile location. This allows for easy support
of different lockfiles per Ruby version or platform.

https://github.com/ruby/rubygems/commit/b54d65bc0a

Co-authored-by: Sutou Kouhei 
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>

[rubygems/rubygems] Simulate Bundler 4 in a better way

2025-06-25T23:06:48+00:00

Overriding the version constant feels too magic and creates a set of
problems. For example, Bundler will lock the simulated version, and that
can cause issues when the lockfile is used under an environment not
simulating Bundler 4 (it will try to auto-install and auto-switch to a
version that does not exist).

On top of that, it can only be configured with an ENV variable which is
not too flexible.

This commit takes a different approach of using a setting, which is
configurable through ENV or `bundle config`, and pass the simulated
version to `Bundler::FeatureFlag`. The real version is still the one set
by `VERSION`, but anything that `Bundler::FeatureFlag` controls will use
the logic of the "simulated version".

In particular, all feature flags and deprecation messages will respect
the simulated version, and this is exactly the set of functionality that
we want users to be able to easily try before releasing it.

https://github.com/rubygems/rubygems/commit/8129402193

Skip to Bundler 4 directly

2025-06-19T01:23:36+00:00

[rubygems/rubygems] Allow enabling "Bundler 3 mode" more easily

2025-06-19T01:23:36+00:00

Currently to test Bundler 3 mode we have to actually edit the version
file to simulate we're running a future version. This is inconvenient.

Instead, allow passing an environment variable, `BUNDLER_3_MODE`, to set
the "working mode" Bundler should use.

This can now be set easily by end users to enable them to try out the
changes in the future version and give us feedback.

It's unclear how version auto-switching should work when this
environment variable is set, so the auto-switching feature will be
disabled in that case.

https://github.com/rubygems/rubygems/commit/4e92e9b209

[rubygems/rubygems] Don't upcase Windows ENV when backing it up

2024-04-25T10:35:47+00:00

I apparently did that to fix some issue with case insensitivity but I
didn't add a spec, and I think not upcasing should not cause issues.

https://github.com/rubygems/rubygems/commit/1b6f23275a

[rubygems/rubygems] Remove unnecessary workaround

2024-04-25T10:35:46+00:00

All supported rubies include the fix.

https://github.com/rubygems/rubygems/commit/9d74b699f5

[rubygems/rubygems] Remove now unnecessary elseif

2024-01-29T03:19:32+00:00

https://github.com/rubygems/rubygems/commit/d05b9e659b

Co-authored-by: Samuel Giddins

[rubygems/rubygems] Properly restore empty env vars

2024-01-29T03:19:31+00:00

https://github.com/rubygems/rubygems/commit/e0d68a8688

Merge RubyGems and Bundler master

2023-01-10T06:53:07+00:00

  from https://github.com/rubygems/rubygems/commit/0635c1423db5d7c461d53bf0c3329bca75de7609

[rubygems/rubygems] Load "bundler/setup" in lib/rubygems.rb

2022-11-10T22:45:31+00:00

Ruby interpreter loads some special gems at startup: did_you_mean,
error_highlight, and syntax_suggest. These gems are loaded before
`bundler/setup` is loaded by `RUBYOPT=-rbundler/setup`.
So, the versions of the gems are not controllable by Gemfile.

This change will `require "bundler/setup"` in rubygems.rb (i.e., before
the special gems are loaded). Now `bundle exec` sets an environment
variable `BUNDLER_SETUP`, and rubygems requires the variable if defined.

See also: https://bugs.ruby-lang.org/issues/19089

https://github.com/rubygems/rubygems/commit/963cb65a2d