github / ruby Public

rubygems/rubygems@f5e408f

Now `$LOADED_FEATURES` list is being maintained by `setup` and
`teardown` and, only libaries under the temporary directory will
be removed.  As `save_loaded_features` removes the rest libraries
other than this test directory, ordinary libraries loaded from
files under rubygems also removed, and often causes constant
redefinition warnings.

rubygems/rubygems@9e1f92a

rubygems/rubygems@97241e0

rubygems/rubygems@32aa540

This method always receives an array, and we require `shellwords`
unconditionally at the top of the file, so `shelljoin` will always be
available.

rubygems/rubygems@05c8ac6

rubygems/rubygems@c218d4d

Previously they were printing the original command that was run, and
telling the user to rerun it. However, the command sometimes would not
match the exact command that was run (for example, when using the
`--local` flag), and in any case, it's simpler and more useful to print
the underlying error anyways.

rubygems/rubygems@5bc0d51

…incomplete resolve

In case we have a corrupted lockfile that claims to support a platform, but
it's missing platform specific gems for it, bundler has a check that
detects the situation and forces a re-resolve. The result of this check
is kept under the `@locked_specs_incomplete_for_platformn` instance
variable in `Definition`.

The installer, however, calls `Definition#nothing_changed?` before this
instance variable has been filled, so the result of it is actually
incorrect here since it will claim that nothing has changed, but
something has changed (locked specs are incomplete for the current
platform).

The consequence of this incorrect result is that the installer thinks it
can go on without re-resolving, resulting in the incomplete resolution
from the lockfile being used, and in a crash being triggered due to
that.

The solution is to make sure the `@locked_specs_incomplete_for_platform`
instance variable is filled before `nothing_changed?` gets called.
Moving it to `initialize` makes the most sense, not because it's the
best place for it (we can refactor this later), but because all of the
other "outdated definition" checks are already set there.

rubygems/rubygems@708afdd

This is exclusively about the lockfile.

rubygems/rubygems@d6c6d04

rubygems/rubygems@7326d47

… check

It doesn't really need converged specs, since it's only about the
lockfile.

rubygems/rubygems@9cd6224

This reverts commit 10d2341.
TravisCI clones the head of the target branch, and it may not be
the target commit at that time.

…eleted gems

rubygems/rubygems@8950631

The other way, in particular matching a substring in the gemspec
summary, is brittle and no longer used since Ruby 2.0.

This needed rewriting the specs that depended on that way.

rubygems/rubygems@059dbfa

All supported rubygems versions implement this.

rubygems/rubygems@2130782

The spec was just faking an installed gemspec without any installed gem
backing it up, resulting in `bundle install` claiming that the gem was
already installed when it was not.

rubygems/rubygems@c35531d

Rename method

ruby/irb@619aecb

The 2nd arm64 pipeline is unstable now in Travis. As Cirrus CI has arm64
pipelines, it's not a problem to drop the arm64 pipeline in Travis.

`Reline::Windows` always reads from the console by Windows API
 using fiddle.

ruby/reline@c3bf85f

The gem and bundle commands first load digest via openssl, so loading
the digest gem would cause this warning every time one of these
commands is run:

```
.../lib/ruby/gems/3.0.0/gems/digest-3.1.0/lib/digest.rb:11: warning: already initialized constant Digest::REQUIRE_MUTEX
.../lib/ruby/3.0.0/digest.rb:7: warning: previous definition of REQUIRE_MUTEX was here
```

ruby/digest@1617261

ruby/digest@5184207

ruby/digest@5667900

ruby/digest@c15cbcd