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
Let them run against the version resolved by the `test_gems.rb` gemfile.
This should fix ruby-core CI job that was broken by the release of rake
13.3.0.
- 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
`make test-bundler-parallel` prints many errors, so try to
downgrade rake version.
```
219) bundle install --standalone run in a subdirectory with --binstubs creates stubs that can be symlinked
Failure/Error:
raise <<~ERROR
#{error_header}
----------------------------------------------------------------------
#{stdboth}
----------------------------------------------------------------------
ERROR
RuntimeError:
Commands:
$ /home/ko1/ruby/build/trunk/ruby -I/home/ko1/ruby/src/trunk/spec/bundler -r/home/ko1/ruby/src/trunk/spec/bundler/support/artifice/compact_index.rb -r/home/ko1/ruby/src/trunk/spec/bundler/support/hax.rb /home/ko1/ruby/src/trunk/tmp/2.13/gems/system/bin/bundle config set --local path /home/ko1/ruby/src/trunk/tmp/2.13/bundled_app/bundle
# $? => 0
Invoking `/home/ko1/ruby/build/trunk/ruby -I/home/ko1/ruby/src/trunk/spec/bundler -r/home/ko1/ruby/src/trunk/spec/bundler/support/artifice/compact_index.rb -r/home/ko1/ruby/src/trunk/spec/bundler/support/hax.rb /home/ko1/ruby/src/trunk/tmp/2.13/gems/system/bin/bundle install --standalone --binstubs` failed with output:
----------------------------------------------------------------------
[DEPRECATED] The --binstubs option will be removed in favor of `bundle binstubs --all`
Could not find compatible versions
Because every version of rails depends on rake = 13.3.0
and rake = 13.3.0 could not be found in rubygems repository https://gem.repo1/ or installed locally,
rails cannot be used.
So, because Gemfile depends on rails >= 0,
version solving has failed.
Fetching gem metadata from https://gem.repo1/...
Resolving dependencies...
----------------------------------------------------------------------
Shared Example Group: "bundle install --standalone" called from ./spec/bundler/install/gems/standalone_spec.rb:532
# /home/ko1/ruby/src/trunk/spec/bundler/support/command_execution.rb:26:in 'Spec::CommandExecution#raise_error!'
# /home/ko1/ruby/src/trunk/spec/bundler/support/subprocess.rb:66:in 'Spec::Subprocess#sh'
# /home/ko1/ruby/src/trunk/spec/bundler/support/helpers.rb:216:in 'Spec::Helpers#sys_exec'
# /home/ko1/ruby/src/trunk/spec/bundler/support/helpers.rb:107:in 'Spec::Helpers#bundle'
# /home/ko1/ruby/src/trunk/spec/bundler/install/gems/standalone_spec.rb:482:in 'block (3 levels) in <top (required)>'
# /home/ko1/ruby/src/trunk/spec/bundler/spec_helper.rb:107:in 'block (4 levels) in <top (required)>'
# /home/ko1/ruby/src/trunk/spec/bundler/spec_helper.rb:107:in 'block (3 levels) in <top (required)>'
# /home/ko1/ruby/src/trunk/spec/bundler/support/helpers.rb:355:in 'block in Spec::Helpers#with_gem_path_as'
# /home/ko1/ruby/src/trunk/spec/bundler/support/helpers.rb:369:in 'Spec::Helpers#without_env_side_effects'
# /home/ko1/ruby/src/trunk/spec/bundler/support/helpers.rb:350:in 'Spec::Helpers#with_gem_path_as'
# /home/ko1/ruby/src/trunk/spec/bundler/spec_helper.rb:106:in 'block (2 levels) in <top (required)>'
```
Necessary changes to get tests passing are:
* Rewrite one "out of memory" error spec to not define a subclass inside
a RSpec context block. Due to some [JRuby issue], that's failing in
JRuby 10, so I rewrote the test so that the Bundler process really
goes OOM and that class definition is not necessary.
* JRuby 10, even if Ruby 3.4-compatible, has not yet adapted backtraces
to include receivers, so our tests need an special case for JRuby when
detecting a test method call inside backtraces.
* Warbler test is upgraded to use JRuby 10. Getting it to pass needs [a
PR] to warbler, so our test is temporarily pointing to that PR.
[JRuby issue]: https://github.com/jruby/jruby/issues/8838
[a PR]: https://github.com/jruby/warbler/pull/557edec85d4c3
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
Unfortunately this requires reverting a previous enhancement of
reinstalling gems if they incorrectly ship with an empty installation
dir.
However, there's no way to distinguish this kind of bad state from a gem
that's empty for real, for example, sorbet-static-and-runtime.
This reverts commit 9720a9b980, and adds a
spec to make sure empty gems are not reinstalled every time.
7c102394af
Only in CI, if two different test runs are started (like `bin/rake
spec:all` does), the second one would not install the dev version of
Bundler and would fail to start.
This commit makes it work the same locally and in CI.
7a5ca6c40f
While working on something else I noticed:
* Usage of uppercased "RUBY" and "JAVA" as platforms, when those don't
really exist.
* Usage of some test gems with "1.0" as gemspec version and "1.0.0" as
actual version.
This commit fixes both inconsistencies to make things more expectable.
e3ec32e247
Instead, build it during setup when in CI.
This should avoid some Windows specific test failures when Bundler
copies the same files from multiple processes and runs into EACESS
errors.
c194a1d753
This gets in the middle if we ever start allowing to build as if using a
different RubyGems version than the one being run.
This could be useful to make `gem rebuild` a little more usable, and
it's already done by Bundler specs which already make this method a noop
when they need this.
I'm not sure forcefully setting this, even if user explicitly specified
something else is helpful.
Since this could potentially prevent gems explicitly setting a constant
RubyGems version from building, I changed the error of incorrect
RubyGems version from a hard error to a warning, since it will start
happening in those cases if we stop overwriting the version.
45676af80d
Specs that use extension gems were failing in the new job but I noticed
that they were using very non standard `extconf.rb` files.
The hack being removed here was added just to make specs pass when run
in ruby-core but it seems the underlying issue has been fixed now, and
it's causing issues with Ruby 3.3 and Windows, so necessary so I'm
removing it and moving on.
5b78275f0e
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
If Gemfile has a lot of dependencies, we have an optimization that uses
the full index in that case, assuming it's going to be faster.
I think this is an old optimization that predates compact index API
times, I believe we no longer need it these days.
Also, since a few releases ago we check for circular dependencies when
resolving by looping through all versions of each name and removing
those that have circular dependencies that would trip up the resolver.
This loop becomes actually very slow when full indexes are used because
to find dependencies of a gemspec, we need to explicitly fetch the
marshaled gemspec (`gemspec.rz` endpoint) for it, so the optimization
has the opposite effect of making things very slow.
2f46289bd3
