ruby.git/lib/bundler/override.rb, branch master

[ruby/rubygems] Move overrides off SpecSet onto LazySpecification

2026-05-08T06:43:47+00:00

SpecSet previously kept its own @overrides and a with_overrides setter
that had to be chained on every SpecSet.new(...) site (~13 sites in
Definition alone). Two Codex review rounds both flagged forgotten
chains in different SpecSet construction paths, which is exactly the
class of bug the chain pattern invites: it is purely "remember to
write" with no compiler help.

Move the override list to LazySpecification#overrides instead. The
LazySpec is the natural carrier — it is the value object the resolver
and install paths already pass around, and choose_compatible already
read overrides off it. Override.attach(specs, overrides) is added as
the dual of Override.find_for so Definition (after lockfile load) and
Resolver (after solve_versions) can populate the overrides on every
LazySpec they hand out, and LazySpecification.from_spec carries the
list forward when one LazySpec spawns another. Generic spec types
(StubSpecification, plain Gem::Specification, RemoteSpecification)
are intentionally ignored so generic metadata callers (SelfManager,
materialize-time strict checks) keep their current strict semantics.

SpecSet drops attr_accessor :overrides, the @overrides initialisation,
the with_overrides cascade, and reverts SpecSet#valid? to the strict
matches_current_metadata? check. Every SpecSet.new(...) site in
Definition stops chaining .with_overrides — the LazySpecs already
carry the context.

https://github.com/ruby/rubygems/commit/fc1e8d4d7e

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Capture Gemfile source location for each override

2026-05-08T06:43:43+00:00

Bundler::Dsl#override now records caller_locations(1, 1).first on
each Override so the originating Gemfile line can be surfaced in
later diagnostics.

https://github.com/ruby/rubygems/commit/ef73385cdc

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Fall back from per-gem lookup to an :all override

2026-05-08T06:43:41+00:00

Override.find_for now returns the per-gem entry when present and
otherwise the matching :all entry on the same field. This is the
single dispatch point for overrides in Definition and Resolver, so
the fallback is what wires :all into resolution and lockfile change
detection without further plumbing.

https://github.com/ruby/rubygems/commit/ef24b4eef9

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Consolidate Override lookup with Override.find_for

2026-05-08T06:43:37+00:00

Definition#apply_override_to, Definition#converge_dependencies, and
Resolver#apply_overrides each duplicated the same find expression.
Centralizing it on Override prepares for upcoming fields (and the :all
target) without repeating the predicate in every call site.

https://github.com/ruby/rubygems/commit/0c4424d5f3

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Preserve != exclusions in Override :ignore_upper

2026-05-07T09:24:50+00:00

Switch remove_upper_bounds from a lower-bound allow-list to an
upper-bound reject-list so that operators other than <, <=, and ~>
are kept verbatim. The previous logic, inherited from
Shopify/bundler-ignore-dependency, dropped != exclusions and could
silently re-allow versions the user had explicitly pinned out
(e.g. >= 1.0, != 1.5.0, < 2.0 collapsed to >= 1.0).

https://github.com/ruby/rubygems/commit/7d73d9e035

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Add Bundler::Override value object

2026-05-07T09:24:49+00:00

Introduce a value object that holds a target/field/operation triple
for the upcoming Gemfile `override` DSL. apply_to dispatches on the
operation: a version spec string replaces the requirement absolutely,
:ignore_upper strips < and <= while folding ~> into >=, and nil
collapses to Gem::Requirement.default. The :ignore_upper logic is
taken from Shopify/bundler-ignore-dependency.

https://github.com/ruby/rubygems/commit/4c2cafa4e8

Co-Authored-By: Claude Opus 4.7 (1M context)