The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.
a96afc5351
We now run specs against a single version, so I prefer to keep a single
branch. Once we bump the major version, this will need very little
updates, and that seems fine.
3866d25a00
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 realized `--redownload` is not a good name, because it does not
necessarily redownloads gems. It only forces reinstallation even if gem
is already installed.
So I believe `--force` is actually a better name and the introduction of
`--force` was a misunderstanding of what the `--force` flag did at the
time.
Let's cancel the deprecation of `--force`.
For now the `--redownload` alias is left around until we decide what to
do with it.
It only affected the `--path` flag which is actually getting removed, so
I don't think it makes sense to make such change. The current behavior
is reasonable and I tried to codify it with a few more specs.
6f520eb146
Originally, all the specs in this file were put inside a shared examples
block, and since then all specs were run only changing the cwd (either
from root, or a subdirectory).
This was in d7291700d0, to cover a fix in
the `bundler_path` method.
However, reverting that fix does not make any of the specs in either of
the main blocks fail! Only an unrelated spec of `bundle install
--standalone --local` fails.
The reason is that all specs set `path` to an absolute path, making the
fix essentially uncovered.
In order to simplify the file structure and improve runtime, I
completely removed the shared examples block, and only run main specs
for the root directory. Then I added a couple of extra specs to cover
the original bug fix.
This cuts runtime of this spec file in half, from 1m30s to 45s on my
laptop.
cc506f17e0
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
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
The mirror probing spec file was moved to our regular suite, which runs
in parallel, recently. These specs rely on starting and stopping actual
servers in localhost, but this does not play nice with parallelization,
because a spec may kill the webserver another spec has created.
This commit moves mirror probing specs to not need to start servers in
localhost and do something more similar to what the other specs do.
ca9a19706f
The "ignore" attribute is a RubyGems thing to mark when a installed gem
should be ignored for activation because its extensions are not properly
compiled.
In the case of gems from path sources, the warning is not accurate
because extensions are compiled into the local lib path, which is not
where RubyGems leaves its sentinel `gem.build_complete` file.
Also, there's a single version of each gem in the path source available
to Bundler, so we always certainly want to consider that for activation
and never makes sense to ignore it.
ec5d33695e
If you have
```
gem "rails", git: "https://github.com/rails/rails"
```
and then explicitly pin to an older ref, like
```
gem "rails", git: "https://github.com/rails/rails", ref: "99bacb5aa8"
```
Then `bundle install` fails, because locked sources fail to be updated
to use the new source.
This commit fixes the problem by making sure get their source properly
replaced.
5de8c2e0cf
- 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
They read like this:
```
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/util.rb:13: warning: method redefined; discarding old rfc1123_date
/opt/hostedtoolcache/Ruby/3.4.3/x64/lib/ruby/3.4.0/cgi/util.rb:225: warning: previous definition of rfc1123_date was here
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/util.rb:34: warning: method redefined; discarding old pretty
/opt/hostedtoolcache/Ruby/3.4.3/x64/lib/ruby/3.4.0/cgi/util.rb:246: warning: previous definition of pretty was here
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/escape.rb:16: warning: method redefined; discarding old escape
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/escape.rb:29: warning: method redefined; discarding old unescape
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/util.rb:13: warning: method redefined; discarding old rfc1123_date
/opt/hostedtoolcache/Ruby/3.4.3/x64/lib/ruby/3.4.0/cgi/util.rb:225: warning: previous definition of rfc1123_date was here
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/util.rb:34: warning: method redefined; discarding old pretty
/opt/hostedtoolcache/Ruby/3.4.3/x64/lib/ruby/3.4.0/cgi/util.rb:246: warning: previous definition of pretty was here
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/escape.rb:16: warning: method redefined; discarding old escape
/home/runner/work/rubygems/rubygems/bundler/tmp/gems/base/ruby/3.4.0/gems/cgi-0.5.0.beta2/lib/cgi/escape.rb:29: warning: method redefined; discarding old unescape
```
The problem is that `rspec` loads `erb` for its configuration, which
loads `cgi/util` from system gems.
Then our tests change the `$LOAD_PATH` to make test gems installed in
tmp visible to `require`, and then they all require `cgi` as a
transitive dependency of `rack-test`, this time from `tmp` gems. This
causes system and test specific copies to be mixed together and these
warnings to be printed, but we have also observed failures in some tests
with errors like
> class variable @@accept_charset of CGI::Util is overtaken by CGI::Escape
This changes should also fix those failures.
The fix is to require all of `rack-test` (including `cgi`) before we
have changed the `$LOAD_PATH`. Because the `$LOAD_PATH` is unchanged,
RubyGems respects the version of `cgi` activated by RSpec, avoiding the
double loads.
34e75465c6
In frozen mode, the previous logic would not set the platform locked
originally in the materialized specification, and that would trigger the
warning about insecure materialization incorrectly.
a18001e10c
If both a native and a generic version are locked, but the native
version is incompatible with the running Ruby, Bundler will still keep
the native version in the lockfile, since it could be potentially useful
when using other rubies.
However, when `bundle update` is run, this was not the case because the
locked native gems were not using the right source when materializing.
They were using the lockfile source instead of the Gemfile source, and
that meant they could not be found when materializing, because the
lockfile source always uses local mode so does not see them.
The effect of this was normally that they were incorrectly removed from
the lockfile and a strange "this spec has been possibly yanked" was
printed in verbose mode. However, in certain situations (i.e., when the
generic gem would bring extra dependencies), it could also make `bundle
update` crash.
The solution is, when adding this extra locked specs to the result after
resolving, maybe sure they inherit the source from the resolved specs,
so they can be found when materializing.
`bundle install` did not have the issue because it passes locked specs
to the resolver, and assigns the right source to them in
`Definition#converge_locked_specs`.
91ce881fda
That restores support for compact index dummy implementations that only lists
versions, without checksums or dependencies.
This format is undocumented, so we may want to get rid of it in the
future. However, some of our tests rely on it, and some implementations
did use it (gems.mutant.dev at least). And the way the code was written
suggest that support was intentional.
So for now, we should restore it.
0427d8c983
* Increase timeout to fix flaky tests?
* Fix bundler test - wording changed.
expect "fatal: Remote branch deadbeef not found in upstream origin" to
include "Revision deadbeef does not exist in the repository"
If a custom rubygems source URI is long enough, Bundler may end up
raising an `ENAMETOOLONG` error and crash.
This commit fixes the problem by trimming the cache slug size to fit
usual OS requirements.
df40ff1e14
Co-authored-by: mbclu <mbclu@users.noreply.github.com>
Co-authored-by: martinemde <martinemde@users.noreply.github.com>
