Running everything in `bundled_app` by default causes the `bundled_app`
helper to be used everytime, and that will create a scoped bundled_app
folder if it does not exist. That causes `bin/rake spec:deps` to create
an empty `tmp/2.1/bundled_app` folder which is a bit weird.
This commit changes specs to not switch to a (possibly empty)
bundled_app directory when not necessary (for example, when running
`gem` commands in order to setup test dependencies).
4bf89c0705
I spent quite a while on this and I have not been able to reproduce or
even understand how the original issue would happen. I also suspect it
never actually reproduced the original problem properly.
Since I'm in the middle of migrating all specs away from touching the
network, I decided to remove it since I can't write an equivalent spec
without being able to understand the original problem.
c9dfa20877
I plan to introduce a `base_system_gems` helper to actually install gems
from `base_system_gem_path` into system gems but that would collapse
with an existing helper.
714c209e62
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.
1cb3e009fc
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.
8129402193
Since we no longer pass ruby CLI flags in our spec commands, we no
longer need the previous workaround and can get the realworld code
tested.
fd92c855fb
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.
4e92e9b209
- the x64-mingw32 platform has been superseded by x64-mingw-ucrt
- the mingw-ucrt platform is present as of Windows 10, which was released 10 years ago in 2015 and all versions prior to 10 are end-of-life and 10 will be by mid October 2025
- newer rubies use the mingw-ucrt platform instead of the mingw32 platform, meaning using the deprecated platform can cause issues during gem installation
b9d871022e
This has the following benefits:
* Avoid duplicated work in some specs that first build a repo, and then
overwrite it with a completely different set of gems.
* Reduce RSpec nesting and improve readability.
* The change also made surfaces several specs that were incorrect since
they were unintentionally not testing the right thing.
ed430883e0
These changes were included when adding bundler plugin hooks for
`Bundler.require`, but they seem completely unrelated to that feature,
and have caused several issues.
8d56551dcf
the overwritten binstub in the test has a final new line that makes it
not match "OMG" exactly from the beginning, that's why the test passes,
but `bintubs` command without `--force` flag is not supposed to update
the binstub.
This change fixes the test to test what's supposed to update the
binstub, and also fixes the assertion that that it will fail in the
future if `--force` stops updating the binstub.
dfc9023337
This was introduced by 0b7be7bb77, because
the original patch was not adapted to some recent refactorings.
0bca60d6e5
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
