| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/rubygems/rubygems/commit/d1247472b9
|
|
* 0.1s is really short and fails in CI: #3622
https://github.com/rubygems/rubygems/commit/d8495ae1c1
|
|
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
'require'
https://github.com/rubygems/rubygems/commit/5995394ec4
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/d490309d75
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
Since `rake package` started printing to stdout by default, we get these
warnings printed when running rubygems tests:
```
$ rake
Run options: --seed 6097
# Running:
...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................mkdir -p pkg
mkdir -p pkg/pkgr-1.2.3
rm -f pkg/pkgr-1.2.3/x
ln x pkg/pkgr-1.2.3/x
rm -f pkg/pkgr-1.2.3/y
ln y pkg/pkgr-1.2.3/y
cd pkg/pkgr-1.2.3
cd -
....
Finished in 50.578889s, 43.0812 runs/s, 134.8191 assertions/s.
2179 runs, 6819 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to /home/deivid/Code/rubygems/coverage. 8080 / 8978 LOC (90.0%) covered.
```
The reason is that, although these tests wrap the
`Rake.application["package"].invoke` with a `capture_io` block, the rake
application initialization happens outside of this block, and a copy of
`$stdout` is saved in there, and that's where the task prints. So the
`capture_io` `$stdout` and `$stderr` dance is not effective.
To fix, we move the `Rake` application initialization inside the
`capture_io` block.
https://github.com/rubygems/rubygems/commit/7f6e2398a5
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/f4fe949dfa
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/f3da3c1190
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
* JRuby doesn't support multi-line -e.
https://github.com/rubygems/rubygems/commit/1fb6657a7d
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
default gems
* Test that the correct version is loaded and that the default gem is
not loaded at all.
https://github.com/rubygems/rubygems/commit/ee08508b2a
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
* But not enforce that error looks like
/full/path/to/ruby/bin/ruby: No such file or directory
but instead allow
truffleruby: No such file or directory
A typical output for gem_make.out looks like:
current directory: /.../rubygems/tmp/test_rubygems_112388/gemhome/gems/a-2
/.../ruby-2.6.6/bin/ruby -I /.../rubygems/lib -r ./siteconf20200422-112388-nyrcy0.rb extconf.rb ''
/.../ruby-2.6.6/bin/ruby: No such file or directory -- extconf.rb (LoadError)
https://github.com/rubygems/rubygems/commit/e6e08882cc
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
* When testing in the rubygems/rubygems repository, the previous code would
move the lib/ dir at the end of $LOAD_PATH, which would cause to load
a mix of lib/ RubyGems and in-stdlib-dir RubyGems, which blows up.
https://github.com/rubygems/rubygems/commit/f6f6f00ed1
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
test_activate_via_require_respects_loaded_files does and tests
* Clearly require the benchmark stdlib instead of far away in test_case.rb
https://github.com/rubygems/rubygems/commit/d74b9ca04c
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/382642a0d4
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
In the cases where the initial manually `-I` path resolution succeeded,
we were passing a full path to the original require effectively skipping
the `$LOADED_FEATURES` cache. With this change, we _only_ do the
resolution when a matching requirable path is found in a default gem. In
that case, we skip activation of the default gem if we detect that the
required file will be picked up for a `-I` path.
https://github.com/rubygems/rubygems/commit/22ad5717c3
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
Our check for `-I` paths should not go through all activated gems.
https://github.com/rubygems/rubygems/commit/00d98eb8a3
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
but rake is not specified as dependency.
https://github.com/rubygems/rubygems/commit/75fe5475b6
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/10cc79ee21
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/a82a77251d
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/e6cabc3f1e
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/5e6d82b1f2
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/73c199b087
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
The logging to $stderr is only happening due to a bug in `FileUtils`.
Logging messages are not errors.
https://github.com/rubygems/rubygems/commit/4d1b6659e6
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
So that I can add a separate test that doesn't set it.
https://github.com/rubygems/rubygems/commit/5726cb418c
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/c58e711598
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
https://github.com/rubygems/rubygems/commit/7ecc216505
Notes:
Merged: https://github.com/ruby/ruby/pull/3184
|
|
not only when !w but also when w == WAITPID_LOCK_ONLY.
See also: f7c0cc36920a4ed14a3ab1ca6cfdf18ceff1e5d5 and a2264342063260d660b99872eaf5080f6ab08e81.
We thought this change was an oversight in the latter commit.
Without this change, the test fails like:
$ make test-all TESTS="../test/ruby/test_process.rb -n test_exec_failure_leaves_no_child" RUN_OPTS="--jit"
...
1) Failure:
TestProcess#test_exec_failure_leaves_no_child [/home/k0kubun/src/github.com/ruby/ruby/test/ruby/test_process.rb:2493]:
Expected [[26799, #<Process::Status: pid 26799 exit 127>]] to be empty.
Co-Authored-By: Yusuke Endoh <mame@ruby-lang.org>
|
|
with MJIT worker enabled
The problem:
```
$ ruby -ropen3 --jit -e 'Open3.capture2e("cmake") rescue nil;binding.irb'
irb(main)[01:0]> Process.waitall
=> [[10656, #<Process::Status: pid 10656 exit 127>]]
$ ruby -ropen3 -e 'Open3.capture2e("cmake") rescue nil;binding.irb'
irb(main)[01:0]> Process.waitall
=> []
```
Not sure why it's happening yet, but first I'd like to prevent trunk-mjit-wait
from failing like http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/2929075.
|
|
just for a case. In addition, this change suppresses unused variable
warning.
|
|
|
|
This reverts commit 93d1588c782ab9d61699f98b6c64d7f0ab8121c0.
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
This reverts commit 0da416ab170dbe1cbd530a5a7c5e8128910014b2.
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Tests using credentials shouldn't be leaving side effects.
https://github.com/rubygems/rubygems/commit/975bcafdfc
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Instead, make each test cleanup after itself.
https://github.com/rubygems/rubygems/commit/e0aba9d64f
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
https://github.com/rubygems/rubygems/commit/4f694f4fb7
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
https://github.com/rubygems/rubygems/commit/2ac557d008
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
https://github.com/rubygems/rubygems/commit/b0c55c76ca
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
and `Gem::Specification.stubs_for`
The rationale is that:
* The change has caused realworld issues. See for example
https://github.com/ruby/did_you_mean/issues/117 and specifically [this
comment](https://github.com/ruby/did_you_mean/issues/117#issuecomment-482733159)
for a great explanation of the issue it caused for `did_you_mean`.
* The change also causes problems for our development workflows. For
example, because of it, our `bundler` specs cannot currently be run with
`bin/rake` and we have to use `bin/rspec` or `bin/parallel_spec`
directly. The explanation for this is:
- Our specs install test dependencies to `tmp` before running specs.
- `rake` is one of these test dependencies.
- Before installing each test dependency, we check whether it has
matching installed specs: https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/bundler/spec/support/rubygems_ext.rb#L109-L114.
- Normally, if `rake` has not yet been installed to `tmp`, this check
fails and `rake` is installed, but since the loaded specs are now
added to `Gem::Specification.stubs` and `rake`'s specification _is_
loaded because we're running through `bin/rake`, the check incorrectly
assumes that `rake` is already installed to `tmp` and skips
installation.
- At a later point the specs check whether `rake` is actually
installed and fail if it's not: https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/bundler/spec/support/builders.rb#L372-L383
Essentially, both of the issues are the same. If at runtime we change
the location of gems, we'll _want_ to not consider loaded specifications
when dealing with the new gem location, because the loaded
specifications have not been loaded from there. Loaded specifications is
something different from installed stub specifications and those should
not be mixed.
The PR still seemed to have fixed an issue, so I did my archaeology job
and investigated the original issue to double check if reverting is ok.
The logs for the original error can be found here:
https://ci.appveyor.com/project/rubygems/rubygems/build/1172/job/ogubyucpljcv22ux.
So I installed ruby 2.4.4, checked out the commit reference before the
offending PR, and the exact error reproduced. :tada:
```
$ rake test
/home/deivid/Code/rubygems/lib/rubygems/resolver.rb:231:in `search_for': Unable to resolve dependency: user requested 'bundler (= 1.16.2)' (Gem::UnsatisfiableDependencyError)
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:283:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `each'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_by'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `with_index'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:52:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:69:in `with_no_such_dependency_error_handling'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:51:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:165:in `initial_state'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:106:in `start_resolution'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:64:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:42:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:188:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:396:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:408:in `resolve_current'
from /home/deivid/Code/rubygems/lib/rubygems.rb:243:in `finish_resolve'
from /home/deivid/Code/rubygems/lib/rubygems/rdoc.rb:13:in `<top (required)>'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/test_case.rb:1563:in `<top (required)>'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `require'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `<top (required)>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `require'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `block in <main>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `select'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `<main>'
rake aborted!
Command failed with status (1)
Tasks: TOP => test
```
Now the explanation of the error:
* Rubygems base `TestCase` class requires `bundler` because some tests
use `bundler`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/test_case.rb#L26
* That `require` (our custom rubygems require) would activate the
default bundler spec (1.16.1 for ruby 2.4.4) but then overwrite it with
a 1.16.2 version (the locally provided bundler those days) due to [this
old
hack](https://github.com/rubygems/bundler/blob/9f7bf0ac3ab8d995e3a274cec3c292a5203f4534/lib/bundler/version.rb#L7-L23).
* Rubygems base `TestCase` class requires `rubygems/rdoc`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/test_case.rb#L1536
* And that file ends up calling `Gem.finish_resolve`:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems/rdoc.rb#L13
* `Gem.finish_resolve` adds the currently loaded specs to the
resolution:
https://github.com/rubygems/rubygems/blob/2bbcdcde08b90d4ef03da8fb1f7a8a3313e13bb8/lib/rubygems.rb#L235
* That means it would try to resolve bundler 1.16.2, but no
specification for that version was installed since the default was
1.16.1. That explains why upgrading to rubygems 2.7.7 fixed the issue,
since it provided bundler 1.16.2 by default so there was not bundler
version discrepancy.
After understanding the error, I conclude that:
* Only this part of the original patch was actually needed to resolve
the error, not any of the changes in `Gem::Specification.stubs` and
`Gem::Specification.stubs_for`:
```diff
diff --git a/lib/rubygems/test_case.rb b/lib/rubygems/test_case.rb
index f1cd3d274c..92c848e870 100644
--- a/lib/rubygems/test_case.rb
+++ b/lib/rubygems/test_case.rb
@@ -13,6 +13,15 @@ else
require 'rubygems'
end
+# If bundler gemspec exists, add to stubs
+bundler_gemspec = File.expand_path("../../../bundler/bundler.gemspec", __FILE__)
+if File.exist?(bundler_gemspec)
+ Gem::Specification.dirs.unshift File.dirname(bundler_gemspec)
+ Gem::Specification.class_variable_set :@@stubs, nil
+ Gem::Specification.stubs
+ Gem::Specification.dirs.shift
+end
+
begin
gem 'minitest'
rescue Gem::LoadError
```
So, I propose to revert adding loaded specification to
`Gem::Specification.stubs` and `Gem::Specification.stubs_for` because I
think it's safe, it fixes the issues caused by their addition, and it
simplifies `Gem::Specification` code, which is already complicated
enough.
https://github.com/rubygems/rubygems/commit/5269cd617c
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
(cached) instance.
https://github.com/rubygems/rubygems/commit/00b3f55562
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Originally, the call to `.stubs_for` allowed to incrementally populate
the `@@stubs_by_name` (especially see the `"#{name}-*.gemspec"` pattern
in 4fa03bb7aac9f25f44394e818433fdda9962ae8d). Now it looks like it
expects that all stubs are loaded, but the `.stubs_for` still matches
the .gemspec files by the `name` pattern:
https://github.com/rubygems/rubygems/blob/6d45e0f7ac1caca22900e39f703e226c4cfdebf7/lib/rubygems/specification.rb#L845
I think this was done by mistake incrementally by PR #1239 and
4cee8ca9199ac7b3ab8647e0b78615f55d3eb02b. I think the best option is to
get back to the original implementation, to let RubyGems incrementally
populate the array. Other option would be to replace the logic in
`.stub_for` by call to `.stubs`, but the means the performance
improvement from the original commit was lost.
https://github.com/rubygems/rubygems/commit/4d0e18185a
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
Otherwise if this test file is run in isolation, this test will fail.
https://github.com/rubygems/rubygems/commit/79da003948
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
The file was removed at
https://github.com/rubygems/rubygems/commit/65b709b095b8354ac2620d1a5d7d537e539f6498,
shipped with rubygems 2.6.5.
https://github.com/rubygems/rubygems/commit/739159a120
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
I believe these are most certainly due to a problem outside of rubygems.
I'm skipping these at least until webrick officially supports jruby
(defining "officially" as "webrick's CI passes on jruby").
https://github.com/rubygems/rubygems/commit/4fca025358
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
This requirement was introduced 14 years ago in
7ce7039b390440754954df5efea619e9f57ef823, and I don't think it's
necessary anymore. I made several tests introducing UTF-8 characters in
gemspec files and generating indexes out of them, and couldn't find any
issues. Gemspecs are read with UTF-8 encoding these days.
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
This code is not necessary and has the bad side effect of causing
test failures in cascade once a single test inside the file fails.
See https://github.com/rubygems/rubygems/runs/538978838 for an example.
https://github.com/rubygems/rubygems/commit/2291d32915
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
https://github.com/rubygems/rubygems/commit/44ebbded12
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
raised while trying to activate a gem
https://github.com/rubygems/rubygems/commit/4da54a8e8b
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
|
In ruby 2.7.0, there's a slight change in bundler's default gemspec file
where the executable folder of the bundler gem is `libexec` instead of
`exe`. I made that change in https://github.com/ruby/ruby/pull/2380 to
try to simplify the integration of the `bundler` gem with upstream,
minimizing the number of changes that need to be made to the gemspec to
adapt to the structure of ruby-core.
That worked ok, expected for this issue. The new name of the folder
including the executable files uncovered a bug in rubygems, which is the
following:
* In order to be able to use newer versions of default gems, `rubygems`
ships with a customized `require` that has knowledge about which files
belong to which default gem. If one of these files is required,
`rubygems` will detect that and activate its gem mechanism to choose the
newest version of the corresponding default gem present in the system
(unless a different version has already been activated). It's this part
of the custom require:
https://github.com/rubygems/rubygems/blob/ea3e6f194df500b028b52b3b64decbd3df1d5ab0/lib/rubygems/core_ext/kernel_require.rb#L77-L85
* In order to do that, `rubygems` registers a map of default gems and
their files when it is first required:
https://github.com/rubygems/rubygems/blob/ea3e6f194df500b028b52b3b64decbd3df1d5ab0/lib/rubygems.rb#L1247-L1276
As explained in the method's header, two types of default gem
specifications are supported. One of the formats is the style used by
some ruby-core gemspec files, where paths inside the `spec.files` array
don't include the `spec.require_paths` part. So in this "old style", if
a gem ships with a `lib/bundler.rb` file, it will be registered in this
array as `spec.files = ["bundler.rb"]`, not as `spec.files =
["lib/bundler.rb"]`. The `Gem.register_default_spec` method "detects"
this style by making sure that none of the files in the `spec.files`
array start with any of the `spec.require_paths`.
* Since in ruby 2.7 the default specification file of the `bundler` gem
includes a `libexec/bundle` file, this check would no longer work
correctly, because even though the specification file is still "old
style", it has one registered file which starts with "lib", one of the
"require paths" of the gem.
* This means that the gem is incorrectly detected as "new style", but
since none of the paths start with "lib/", no files are actually
registered, so the gem is not being considered a default gem, and thus
the default version is always used with no possibility of being
"upgraded".
The fix of the problem is simple: check that no files start with `lib/`
(or any other require paths), instead of with "lib" which doesn't
exclude other potential "non requirable folder" starting with lib, like
in the `bundler` case.
https://github.com/rubygems/rubygems/commit/94df740c2b
Notes:
Merged: https://github.com/ruby/ruby/pull/3092
|
