Followup to https://github.com/rubygems/rubygems/pull/8436
It fixed showing the template when requiring a non-existant file but
user code can do much more than just trying to require other code.
I encountered this particular case because of load order issues, where a library wasn't able
to properly require itself when loaded before some other library.
1c910e5afe
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
After introducing the `simulate_version` setting, that's another call to
`Bundler#Settings#[]` that gets in the middle and makes these specs fail
when run in isolation.
722360e98e
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
These specs load artifice before Bundler boots because of their global
rubygems source. Artifice in turn loads `rack`, `rack-test`, and
`tmpdir` which in turn load `fileutils`.
Because of this, a missing `require` of `fileutils` in RubyGems would
not be caught by specs.
Loading artifice is not necessary for most of these specs, so remove the
global source to avoid it.
aad871c997
As Set is now a core collection class, it should have special inspect
output. Ideally, inspect output should be suitable to eval, similar
to array and hash (assuming the elements are also suitable to eval):
set = Set[1, 2, 3]
eval(set.inspect) == set # should be true
The simplest way to do this is to use the Set[] syntax.
This deliberately does not use any subclass name in the output,
similar to array and hash. It is more important that users know they
are dealing with a set than which subclass:
Class.new(Set)[]
# this does: Set[]
# not: #<Class:0x00000c21c78699e0>[]
This inspect change breaks the power_assert bundled gem tests, so
add power_assert to TEST_BUNDLED_GEMS_ALLOW_FAILURES in the workflows.
Implements [Feature #21389]
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
As showed by the unskiped spec, on Windows trying to use the 0.0.0.0
interface raises this error, and it's raised as a generic system error
when trying to create a `bundler.lock` file. Here's is a better place to
handle that.
e32c5a9e5c
