If a gem is required circular, and there are unresolved specs depending
on it, we may end up in an activation conflict.
The solution is to not try to activate unresolved gems when requiring a
default gem, regardless of it having already been activated or not.
3b2b8f4e3e
The following conditions must be met:
* A default gem is required.
* A previous require left some gems unresolved, and those dependencies
themselves depend on the default gem.
In this case, rubygems require will first activate the default version
of the gem, then try to activate another unresolved version of the
default gem that conflicts with the first activation.
The solution is, if we are in the middle of requiring a default gem,
skip this step, because we have already activated it successfully.
8cd5608db5
Co-authored-by: Stan Hu <stanhu@gmail.com>
Original output:
~~~
Failure: test_realworld_upgraded_default_gem(TestGemRequire): <false> is not true.
/mnt/test/rubygems/test_require.rb:474:in `test_realworld_upgraded_default_gem'
471: File.write(path, code)
472:
473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip
=> 474: assert $?.success?
475: refute_empty output
476: assert_equal "999.99.9", output.lines[0].chomp
477: # Make sure only files from the newer json gem are loaded, and no files from the default json gem
~~~
New output:
~~~
Failure: test_realworld_upgraded_default_gem(TestGemRequire)
/mnt/test/rubygems/test_require.rb:475:in `test_realworld_upgraded_default_gem'
472:
473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip
474: refute_empty output
=> 475: assert_equal "999.99.9", output.lines[0].chomp
476: # Make sure only files from the newer json gem are loaded, and no files from the default json gem
477: assert_equal ["#{@gemhome}/gems/json-999.99.9/lib/json.rb"], output.lines.grep(%r{/gems/json-}).map(&:chomp)
478: assert $?.success?
<"999.99.9"> expected but was
<"/mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem.rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError)">
diff:
? 999 .99.9
? /mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError)
? ??? ????
~~~
It is more valuable to check the command output then the error code. If
the command fails for some reason, the output probably contains some
detail, while checking the return code tells not much.
b76062e852
This changes "test/rubygems/test_case.rb" to "test/rubygems/helper.rb",
and "test/rubygems/test_utilities.rb" to "test/rubygems/utilities.rb".
The two files are a helper for tests, not test files. However, a file
starting with "test_" prefix is handled as a test file directly loaded
by test-unit because Rakefile specifies:
```
t.test_files = FileList['test/**/test_*.rb']
```
Directly loading test/rubygems/test_utilities.rb caused "uninitialized
constant Gem::TestCase". This issue was fixed by
59c6820971, but the fix caused a
"circular require" warning because test_utilities.rb and test_case.rb
are now requiring each other.
Anyway, adding "test_" prefix to a test helper file is confusing, so
this changeset reverts the fix and solve the issue by renaming them.
6460e018df
