| Age | Commit message (Collapse) | Author |
|---|
|
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) <noreply@anthropic.com>
|
|
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) <noreply@anthropic.com>
|
|
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) <noreply@anthropic.com>
|
|
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) <noreply@anthropic.com>
|
|
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) <noreply@anthropic.com>
|
|
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) <noreply@anthropic.com>
|
