| Age | Commit message (Collapse) | Author |
|---|
|
- Fix https://github.com/ruby/rubygems/issues/9238
- ### Problem
This is an issue that bites gem maintainers from time to time, with
the most recent one in https://github.com/minitest/minitest/issues/1040#issuecomment-3679370619
The issue is summarized as follow:
1) A gem "X" has a feature in "lib/feature.rb"
2) Maintainer wants to extract this feature into its own gem "Y"
3) Maintainer cut a release of X without that new feature.
4) Users install the new version of X and also install the new
gem "Y" since the feature is now extracted.
5) When a call to "require 'feature'" is encountered, RG will
fail to load the right gem, resulting in a `LoadError`.
### Details
Now that we have two gems (old version of X and new gem Y) with
the same path, RubyGems will detect that `feature.rb` can be loaded
from the old version of X, but if the new version of X had already
been loaded, then RubyGems will raise due to versions conflicting.
```ruby
require 'x' # Loads the new version of X without the feature which was extracted.
require 'feature' # Rubygems see that the old version of X include that file and tries to activate the spec.
```
### Solution
I propose that RubyGems fallback to a spec that's not yet loaded.
We try to find a spec by its path and filter it out in case a spec
with the same name has already been loaded.
Its worth to note that RubyGems already has a
`find_inactive_by_path` but we can't use it. This method only checks
if the spec object is active and doesn't look if other spec with the
same name have been loaded. The new method we are introducing
verifies this.
https://github.com/ruby/rubygems/commit/f298e2c68e
|
|
https://github.com/rubygems/rubygems/commit/e4f1772d80
|
|
activated
https://github.com/rubygems/rubygems/commit/b44bf2ac74
|
|
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
|
|
|
|
user installed gems"
This reverts commit a3edc4abc574b04bcacfae2af188cce7d27bfcf1.
That commit caused test failure with Windows platform.
* https://github.com/ruby/ruby/actions/runs/9289018414/job/25561871390
* https://github.com/ruby/ruby/actions/runs/9289018425/job/25561873060
|
|
installed gems
https://github.com/rubygems/rubygems/commit/0eb6ed8f86
|
|
`--destdir` is given
This was only working for gems also installed in the default gem home.
https://github.com/rubygems/rubygems/commit/47df02dbd9
|
|
When `gem uninstall <gem> --install-dir <dir>` is run, if the version
removed had a plugin, and that same version happened to also be
installed globally, then the plugin stub would fail to be removed.
https://github.com/rubygems/rubygems/commit/4e2fa0be77
|
|
This class handles all logic to handle the list of specifications, given
a set of GEM_PATH directories. Makes `Gem::Specification` has less
responsibilities and will help with fixing some bugs next.
https://github.com/rubygems/rubygems/commit/df280dbbed
|
