We fixed some issues recently where Bundler would try to activate a
pysch spec with missing extensions and crash. However, as a side effect,
we started printing warnings about missing extensions in situations
where we did not warn before.
It may be interesting to warn on these new situations too, but in order
to minimize changes for now, I'm reverting to printing warnings in the
same situations as before.
https://github.com/rubygems/rubygems/commit/51ebff6982
A default gem does not always live in the same place. For example,
Bundler may be installed to `site_dir` when RubyGems have been upgraded.
A more reliable way seems to actually activate the default gem, so that
we can know for sure where it lives.
https://github.com/rubygems/rubygems/commit/c69f6dfb18
If a default version and a regular version of etc are present at the
same time, RubyGems will end up duplicating work and running pristine
twice.
The `etc` gem is special because it's loaded by RubyGems by default.
When doing this, RubyGems will activate the regularly installed version.
The when `gem pristine` runs, it will find to installed specifications
but materialize both to the already activated specification.
Before:
```
$ gem pristine etc --version 1.4.3
Restoring gems to pristine condition...
Building native extensions. This could take a while...
Restored etc-1.4.3
Building native extensions. This could take a while...
Restored etc-1.4.3
```
After:
```
$ gem pristine etc --version 1.4.3
Restoring gems to pristine condition...
Skipped etc-1.4.3, it is a default gem
Building native extensions. This could take a while...
Restored etc-1.4.3
```
https://github.com/rubygems/rubygems/commit/5c279ac56b
If old Bundler versions that unconditionally try to remove this method
are run with RubyGems versions _without_ this method, Bundler crashes
because it tries to remove a method that does not exist.
We need to wait until RubyGems cannot install any Bundler versions that
unconditionally remove this method.
https://github.com/rubygems/rubygems/commit/98804d261d
It would happen when the gem is already installed to multiple GEM_PATHS.
RubyGems was removing duplicate specs without considering the
potentially different `base_dir`. That was causing the gem to be
misidentified as not already installed, and a nil specification getting
returned from the installer as a result, causing the crash.
Solve it by making sure `Gem::Specification.all` really iterates through
all the different specifications in all GEM_PATHs.
https://github.com/rubygems/rubygems/commit/0d8c208f65
Gem command loading errors rely on `#to_s` on the raised exception, but
in the case of `MissingSpecVersionError` that was only the exception
name, making it printed twice and no message at all.
Before:
```
ERROR: Loading command: install (Gem::MissingSpecVersionError)
Gem::MissingSpecVersionError
```
After:
```
ERROR: Loading command: install (Gem::MissingSpecVersionError)
Could not find 'io-wait' (>= 0.a) - did find: [io-wait-0.3.0-java]
Checked in 'GEM_PATH=/Users/deivid/Code/rubygems/rubygems/bundler/tmp/1.1/gems/system' , execute `gem env` for more information
```
https://github.com/rubygems/rubygems/commit/d06944bb2f
I suspect someone could be setting this instance variable, and the
previous changes made that no longer effective.
Also I implemented a previous TOOD in `full_gem_path` the other way
around:
> # TODO: This is a heavily used method by gems, so we'll need
> # to aleast just alias it to #gem_dir rather than remove it.
I made `gem_dir` an alias of `full_gem_path` rather than the opposite.
This alternative change keeps both methods symmetric without deprecating
either of them for now.
https://github.com/rubygems/rubygems/commit/28983973a3
In a `bundle exec` context, the local specification will actually be
part of the known specifications, so RubyGems will assume it has already
been installed, which is not actually true.
This will cause `RequestSet` to rebuild extensions for a gem that's not
actually installed, causing errors.
The fix is to make sure detection of installed activation requests
considers not only that there's a known spec with the same full name as
the one being installed, but also that this spec is installed in the
same gem_home were pretend to install the new gem.
https://github.com/rubygems/rubygems/commit/a8ef1286a6
Every time a gem is not found in the Compact Index API, RubyGems will
fallback to the full index, which is very slow. This is unnecessary
because both indexes should be providing the same gems, so if a gem
can't be found in the Compact Index API, it won't be found in the full
index.
We _do_ want a fallback to the full index, whenever the Compact Index
API is not implemented. To detect that, we check that the API responds
to the "/versions" endpoint, just like Bundler does.
Before:
```
$ time gem install fooasdsfafs
ERROR: Could not find a valid gem 'fooasdsfafs' (>= 0) in any repository
gem 20,77s user 0,59s system 96% cpu 22,017 total
```
After:
```
$ time gem install fooasdsfafs
ERROR: Could not find a valid gem 'fooasdsfafs' (>= 0) in any repository
gem 5,02s user 0,09s system 91% cpu 5,568 total
```
https://github.com/rubygems/rubygems/commit/c0d6b9eea7
Ellen Marie Dash
Leo Arnold
David Rodríguez
Samuel Giddins
Nobuyoshi Nakada
Hiroshi SHIBATA