| Age | Commit message (Collapse) | Author |
|---|
|
Unfortunately this requires reverting a previous enhancement of
reinstalling gems if they incorrectly ship with an empty installation
dir.
However, there's no way to distinguish this kind of bad state from a gem
that's empty for real, for example, sorbet-static-and-runtime.
This reverts commit https://github.com/rubygems/rubygems/commit/9720a9b980d2, and adds a
spec to make sure empty gems are not reinstalled every time.
https://github.com/rubygems/rubygems/commit/7c102394af
|
|
There's no reason to call `converge_specs` when adding additional
lower bound requirements to prevent downgrades, and it actually causes
the extra requirements to be missed sometimes.
Loop over the originally locked specs directly, adding the additional
precaution of not adding the requirement if the Gemfile dependency has
changed and it no longer matches the locked spec.
https://github.com/rubygems/rubygems/commit/5154506912
|
|
These don't really hurt, so I'm not sure why I introduced it.
https://github.com/rubygems/rubygems/commit/85b6b405ac
|
|
are incorrect
Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
https://github.com/rubygems/rubygems/commit/b8e55087f0
|
|
https://github.com/rubygems/rubygems/commit/d8c4754d8f
|
|
https://github.com/rubygems/rubygems/commit/516430c3ec
|
|
Bundler does not really have a concept of "development dependencies",
like RubyGems has. Bundler has the more generic concept of "groups".
Under the hood, the `gemspec` DSL will put gemspec development
dependencies under a `:development` Gemfile group, but there's no reason
to instantiate these as development dependencies, they are regular
runtime dependencies, except that they belong in a group named
:development.
By never instantiating development dependencies at all, we avoid having
to introduce hacks to "undo" the type Bundler does not know about, and I
also think the error messages read better.
https://github.com/rubygems/rubygems/commit/9a06fa5bda
|
|
We have a flaky failure where to equal Bundler specs sneak into the same
SpecSet. This seems like a vector where that could happen so trying this
in case it fixes the flaky.
https://github.com/rubygems/rubygems/commit/a33aeb3c4d
|
|
https://github.com/rubygems/rubygems/commit/55af558124
|
|
https://github.com/rubygems/rubygems/commit/33d91de732
|
|
https://github.com/rubygems/rubygems/commit/a3f365bbaa
|
|
And avoid installing any gems.
https://github.com/rubygems/rubygems/commit/c12700c7e4
|
|
Bundler DSL, in favor of using `platform :windows`
This commit is only deprecation and does not change/remove any actual functionality.
https://github.com/rubygems/rubygems/commit/0ca6dc3984
|
|
https://github.com/rubygems/rubygems/commit/de8b3016db
|
|
Fixes [Bug #21117]
https://github.com/ruby/prism/commit/19d4bab5a0
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12740
|
|
gems are available locally
Filtering out remote specs should only apply where there are locally
installed specs. Otherwise they should always be considered.
https://github.com/rubygems/rubygems/commit/118f8389a1
|
|
When Bundler refuses to install in frozen mode, sometimes it would
incorrectly claim that some dependencies have been added to the Gemfile
when that's not really the case. Fix that by making sure
`locked_dependencies` always has all locked dependencies, even when
unlocking,
Additionally, the suggestion to run `bundle install` is also confusing
when unlocking, since `bundle update` is what has been run. So skip that
part as well when unlocking.
https://github.com/rubygems/rubygems/commit/64d84ad7d8
|
|
options
https://github.com/rubygems/rubygems/commit/5b6077a1e8
|
|
Platforms specific gems not compatible with the current Ruby should not
make `bundle cache` fail and should not get removed from the cache since
they still may be useful in other rubies.
https://github.com/rubygems/rubygems/commit/717b43f565
|
|
And make the current `materialize_strictly` private.
https://github.com/rubygems/rubygems/commit/3fc2129147
|
|
We materializing for installation, we already do this, and we
materializing for cache, it does not seem necessary.
https://github.com/rubygems/rubygems/commit/1a983c6cbc
|
|
https://github.com/rubygems/rubygems/commit/32982fcd33
|
|
And rename it to something better.
https://github.com/rubygems/rubygems/commit/321174d1ad
|
|
https://github.com/rubygems/rubygems/commit/c65b8644e6
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
I think we need this to silence the following warning when running
`bin/console` with Ruby 3.4
```
./bin/console:10: warning: irb was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add irb to your Gemfile or gemspec to silence this warning.
```
https://github.com/rubygems/rubygems/commit/c46230c856
|
|
https://github.com/rubygems/rubygems/commit/9720a9b980
|
|
The previous wording was too specific, there may be situations when the
gem has actually never installed (so never deleted either).
https://github.com/rubygems/rubygems/commit/e4a0d71fbe
|
|
dependencies
For installed specifications, we can ignore any constraints they may
have, since we know they match the current version of Ruby or otherwise
would not be installed.
For remote specifications, we already resolve optimistically without
metadata and retry force-fetching it if necessary.
If in the future we support resolving against a Ruby version different
that the one being run, we'll probably need to change this but now it's
unnecessary and saves some memory.
### Before
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
### After
Total allocated: 259.89 MB (3134199 objects)
Total retained: 115.05 MB (1283779 objects)
https://github.com/rubygems/rubygems/commit/201c1863fc
|
|
specification classes
https://github.com/rubygems/rubygems/commit/7f921aa46e
|
|
They use less memory that way.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
### After
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
https://github.com/rubygems/rubygems/commit/a4ef9c5f56
|
|
Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 277.48 MB (3384318 objects)
Total retained: 117.53 MB (1338657 objects)
### After
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
https://github.com/rubygems/rubygems/commit/c6dc2966c5
|
|
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
### After
Total allocated: 277.44 MB (3383182 objects)
Total retained: 117.55 MB (1338622 objects)
https://github.com/rubygems/rubygems/commit/2d3d6e5015
|
|
Since not every dependency gets referenced.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 295.01 MB (3624335 objects)
Total retained: 119.31 MB (1364474 objects)
### After
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
https://github.com/rubygems/rubygems/commit/61eee39d81
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
Currently evenn if the require actually fails, they suggest that the
file was actually loaded, which is confusing. I reworded them to reduce
this confusion.
|
|
The name "gem" could be confused with RubyGems activation method.
|
|
Most of the stuff is not actually necessary.
|
|
If anything, I think this may be causing some false positives.
|
|
methods:
- Follow up to https://github.com/rubygems/rubygems/pull/8430#discussion_r1927239555.
The maglev platform was not supported by Bundler, so calling
`gem "foo", platforms: ["maglev"]` would raise an error.
The helpers added in the `CurrentRuby` class were used at a time
when maglev was supported (as explained in https://github.com/rubygems/rubygems/commit/45ec86e2e528).
Support of maglev was most likely dropped at some point and the helpers
in the `CurrentRuby` class were not deprecated/removed.
We decided to deprecate them now.
https://github.com/rubygems/rubygems/commit/66388babf8
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12616
|
|
https://github.com/ruby/resolv/commit/3ecfce3626
|
|
A block is part of the Delegator's contract. Ruby 3.4 issues a warning if a block is passed but unused. This commit fixes the warning by adding a block to the argument list.
https://github.com/ruby/weakref/commit/9495ec9191
|
|
dependency
If you force uninstall a dependency but leave other gems depending on
it, those gems will fail to be activated.
In that case, RubyGems prints a rather complicated error:
```
$ rails --version
/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1413:in 'block in Gem::Specification#activate_dependencies': Could not find 'activesupport' (= 8.0.1) among 478 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/Users/deivid/.local/share/gem/ruby/3.4.0:/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/gems/3.4.0' at: /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/gems/3.4.0/specifications/railties-8.0.1.gemspec, execute `gem env` for more information
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1399:in 'Array#each'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1399:in 'Gem::Specification#activate_dependencies'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1381:in 'Gem::Specification#activate'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:283:in 'block in Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Thread::Mutex#synchronize'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/bin/rails:25:in '<main>'
/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/dependency.rb:303:in 'Gem::Dependency#to_specs': Could not find 'activesupport' (= 8.0.1) - did find: [activesupport-7.1.3,activesupport-7.0.8.7] (Gem::MissingSpecVersionError)
Checked in 'GEM_PATH=/Users/deivid/.local/share/gem/ruby/3.4.0:/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/gems/3.4.0' , execute `gem env` for more information
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1411:in 'block in Gem::Specification#activate_dependencies'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1399:in 'Array#each'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1399:in 'Gem::Specification#activate_dependencies'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1381:in 'Gem::Specification#activate'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:283:in 'block in Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Thread::Mutex#synchronize'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/bin/rails:25:in '<main>'
```
With this commit, the error becomes a bit simpler to parse:
```
$ rails --version
/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1421:in 'block in Gem::Specification#activate_dependencies': Could not find 'activesupport' (= 8.0.1) among 478 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/Users/deivid/.local/share/gem/ruby/3.4.0:/Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/gems/3.4.0' at: /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/gems/3.4.0/specifications/railties-8.0.1.gemspec, execute `gem env` for more information
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1407:in 'Array#each'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1407:in 'Gem::Specification#activate_dependencies'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems/specification.rb:1389:in 'Gem::Specification#activate'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:283:in 'block in Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Thread::Mutex#synchronize'
from /Users/deivid/.asdf/installs/ruby/3.4.1/lib/ruby/site_ruby/3.4.0/rubygems.rb:282:in 'Gem.activate_bin_path'
from /Users/deivid/.asdf/installs/ruby/3.4.1/bin/rails:25:in '<main>'
```
And also, we reduce exception based control flow in our code.
https://github.com/rubygems/rubygems/commit/7e48c49f2d
|
|
|
|
https://github.com/rubygems/rubygems/commit/f9bf58573f
|
|
These gems always define their main namespace and I don't think that
will ever change.
https://github.com/rubygems/rubygems/commit/6663cbed53
|
|
- Similar change than https://github.com/rubygems/rubygems/commit/29a1be0008e6,
keep a single source of truth where we store the platform.
The only change worth highlighing is the platform "maglev".
It was not part of the supported platform of dependencies,
so calling `gem 'foo', plaftorm: 'maglev'` would not work.
However, it was supposed to according to https://github.com/rubygems/rubygems/commit/45ec86e2e528.
That's why it was possible to do `Bundler.current_ruby.maglev?` or
`Bundler.current_ruby.maglev_30?`.
I didn't change the current behaviour and maglev is not supported,
though I kept the `*maglev` methods as I believe CurrentRuby is
public API.
https://github.com/rubygems/rubygems/commit/29e219ebcf
|
|
- We keep 2 list of supported ruby versions and each time a new ruby
version is released we need to maintain both list. Forgetting
to update one would prevent users from adding gem for a specific
plaftorm (i.e. https://github.com/rubygems/rubygems/commit/7cd19d824d17 and https://github.com/rubygems/rubygems/commit/5462322f8f0c).
Extracted the list from the Dependency class and moved it to the
CurrentRuby class (which I believe was originally added for that
reason).
https://github.com/rubygems/rubygems/commit/a91edd6c1f
|
|
- Fix https://github.com/rubygems/rubygems/pull/8427
- Similar to https://github.com/rubygems/rubygems/commit/7cd19d824d17.
Tweaked a bit the test supposed to prevent this error by checking
whether the dep respond to these methods.
https://github.com/rubygems/rubygems/commit/62012eaeb6
|
|
Fixes https://github.com/ruby/error_highlight/pull/58
https://github.com/ruby/error_highlight/commit/9ddc1f31a9
|
