ruby.git/spec/bundler/support/env.rb, branch v4.0.3 The Ruby Programming Language [rubygems/rubygems] Remove "double CI" for testing Bundler 4 mode 2025-06-30T03:56:50+00:00 David Rodríguez deivid.rodriguez@riseup.net 2025-06-25T14:20:38+00:00 9e566141cd7405f6e6d9948ba3fb073c6143b684 Since now every functionality that changes in Bundler 4 is under a setting, we can enable that setting to test the new functionality, without having to run our full CI twice. This can actually be seen as increasing coverage, because Bundler 4 functionality will now be tested on Windows, MacOS, or any other environment where previously "Bundler 4 mode" was not running. https://github.com/rubygems/rubygems/commit/1cb3e009fc 
Since now every functionality that changes in Bundler 4 is under a
setting, we can enable that setting to test the new functionality,
without having to run our full CI twice.

This can actually be seen as increasing coverage, because Bundler 4
functionality will now be tested on Windows, MacOS, or any other
environment where previously "Bundler 4 mode" was not running.

https://github.com/rubygems/rubygems/commit/1cb3e009fc
[rubygems/rubygems] Simulate Bundler 4 in a better way 2025-06-25T23:06:48+00:00 David Rodríguez deivid.rodriguez@riseup.net 2025-06-18T20:08:32+00:00 90085f62fb793f47e43b64acf6a32900ba8e6e4d 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 
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
[rubygems/rubygems] Extract logic to manipulate RUBYLIB in specs to a helper 2025-01-16T10:41:11+00:00 David Rodríguez deivid.rodriguez@riseup.net 2025-01-15T19:59:40+00:00 10e7e92badce82f25118b6c0673ea7b3ce97e54d https://github.com/rubygems/rubygems/commit/0057382bb1 
https://github.com/rubygems/rubygems/commit/0057382bb1
[rubygems/rubygems] Make ruby-core check not depend on ENV 2024-09-02T12:31:15+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-08-28T10:30:35+00:00 9d522cc44d256bcad157f9dc351c7dfce146c848 I found it useful to be able to use `GEM_COMMAND` outside of a ruby-core env, so I made the ruby-core env detection not depend on it. https://github.com/rubygems/rubygems/commit/6cb389c290 
I found it useful to be able to use `GEM_COMMAND` outside of a ruby-core
env, so I made the ruby-core env detection not depend on it.

https://github.com/rubygems/rubygems/commit/6cb389c290
[rubygems/rubygems] Stop depending on `pathname` for subprocess launching 2024-06-06T18:44:52+00:00 David Rodriguez deivid.rodriguez@riseup.net 2021-10-18T19:11:12+00:00 da75df2f75648d7ff87e4701874b2b425ca83f71 When launching bundler subprocesses for end to end testing, all of them will load the `spec/support/rubygems_version_manager.rb` file passed as a ruby's `-r` flag. Unfortunately this file depends on `pathname`, so unless we drop that dependency, we can't really test support for including the `pathname` gem in the `Gemfile`. This commit implements some refactorings to avoid loading `pathname` inside `bundler` test subprocesses. https://github.com/rubygems/rubygems/commit/c1f948788c 
When launching bundler subprocesses for end to end testing, all of them
will load the `spec/support/rubygems_version_manager.rb` file passed as
a ruby's `-r` flag.

Unfortunately this file depends on `pathname`, so unless we drop that
dependency, we can't really test support for including the `pathname`
gem in the `Gemfile`.

This commit implements some refactorings to avoid loading `pathname`
inside `bundler` test subprocesses.

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