build(deps): depend on alloy-primitives instead of the alloy umbrella (0.2.0) - #24
Open
dependabot[bot] wants to merge 2 commits into
Open
build(deps): depend on alloy-primitives instead of the alloy umbrella (0.2.0)#24dependabot[bot] wants to merge 2 commits into
dependabot[bot] wants to merge 2 commits into
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
force-pushed
the
dependabot/cargo/alloy-1.0.30
branch
from
October 7, 2025 09:40
b74c3b4 to
d362998
Compare
|
|
lean-apple
changed the title
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
lean-apple
previously approved these changes
Jul 27, 2026
Contributor
Author
|
A newer version of alloy exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged. |
lean-apple
force-pushed
the
dependabot/cargo/alloy-1.0.30
branch
2 times, most recently
from
August 3, 2026 20:00
c05b1eb to
8f64f39
Compare
lean-apple
changed the title
lean-apple
force-pushed
the
dependabot/cargo/alloy-1.0.30
branch
from
August 3, 2026 20:09
8f64f39 to
9f17768
Compare
lean-apple
changed the title
mateo-mro
reviewed
Aug 3, 2026
| # Other | ||
| thiserror = "2.0.11" | ||
| alloy = { version = "0.12.6", optional = true, default-features = false, features = ["std"] } | ||
| alloy-primitives = { version = "1.6", optional = true, default-features = false, features = ["std"] } |
There was a problem hiding this comment.
Existing consumers can still be using alloy 0.12, whose Address and the other primitive types come from alloy_primitives 0.8. This switches the impls to alloy_primitives 1.x, so Cargo will keep both versions and those existing types will no longer implement FromEnvVar. Keeping the feature name does not preserve that API. Could we either retain compatibility for 0.8 or call this out and release it as a breaking change?
The crate uses exactly four alloy items -- Address, Bytes, U256 and FixedBytes -- all of which live in alloy-primitives. Pulling the umbrella crate in to reach them meant tracking alloy's release cadence for two pure re-export shims (alloy and alloy-core). That cadence is the real cost. alloy cut seven breaking lines in eighteen months (0.11 through 2.x), and this repo opened fourteen bump PRs of which thirteen were superseded before they could merge, leaving the dependency stuck on 0.12.6 the whole time. alloy-primitives has been on 1.x since mid-2025, so semver-compatible updates become lockfile-only. The requirement names 1.6.1 as the floor because that is what the graph resolves to today; anything older lacks the primitives this relies on. This is an API break for consumers that enable the `alloy` feature while on alloy 0.12, whose primitives come from alloy-primitives 0.8: cargo keeps 0.8 and 1.x side by side, so their types stop satisfying FromEnvVar. The feature name is unchanged, but that does not preserve those impls.
lean-apple
force-pushed
the
dependabot/cargo/alloy-1.0.30
branch
from
August 3, 2026 20:30
9f17768 to
cd906f6
Compare
Moving the alloy primitives requirement from 0.8 to 1.x changes which types carry the FromEnvVar impls, so consumers enabling the `alloy` feature while on alloy 0.12 lose them. Marking that with a minor bump, which is the breaking position for a 0.x crate, rather than shipping it as a patch.
lean-apple
changed the title
mateo-mro
reviewed
Aug 4, 2026
| alloy::primitives::Address, | ||
| alloy::primitives::Bytes, | ||
| alloy::primitives::U256 | ||
| alloy_primitives::Address, |
There was a problem hiding this comment.
This changes the concrete primitive types that receive FromEnvVar, but the test module still does not exercise any of these implementations. A feature wiring mistake or a parsing regression would compile without proving the public behavior. Could we add one enabled feature test for Address and FixedBytes so the new surface is covered?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the
alloyumbrella dependency withalloy-primitives1.6.1, and releases it as 0.2.0.Does this break our code? No.
default-features = false, so thealloyfeature is never enabled and these impls don't compile in. Uses onlyrust_tracing::trace()(11main.rscall sites); noFromEnvVarusage anywhere. Already resolvesalloy-primitives1.6.1.0.1.3,0.1.4); those tags keep resolving as before.It is still an API break in principle, which is why this ships as 0.2.0 rather than a patch:
alloy0.12 resolvesalloy-primitives0.8 (viaalloy-core^0.8.22), and 0.8 vs 1.x are semver-incompatible, so cargo keeps both side by side. Anyone enabling thealloyfeature while on alloy 0.12 would find theirAddress/Bytes/U256/FixedBytesno longer implementFromEnvVar. Keeping the feature name does not preserve that — thanks @mateo-mro for catching it. No such consumer exists today, so retaining parallel 0.8 and 1.x impl blocks would be maintenance cost for a code path nobody enables.Why drop the umbrella
The crate uses exactly four alloy items —
Address,Bytes,U256,FixedBytes— all inalloy-primitives. Reaching them through the umbrella meant tracking alloy's release cadence for two pure re-export shims (alloy,alloy-core).That cadence is the real cost:
alloycut seven breaking version lines in eighteen months (0.11 → 0.12 → 0.13 → 0.14 → 0.15 → 1.x → 2.x), and this repo opened fourteen bump PRs of which thirteen were superseded before they could merge — leaving the dependency pinned to 0.12.6 the entire time.alloy-primitiveshas been on 1.x since mid-2025, so semver-compatible updates become lockfile-only.The requirement is
"1.6.1"(i.e.^1.6.1, a floor) rather than"=1.6.1". An exact pin would hard-fail consumer resolution the moment anything else in their graph needs 1.7+, since=1.6.1and^1.7have no overlap and cargo cannot keep two same-major copies.No RPC crate is added — the crate has no RPC, provider, transport or network usage, so an
alloy-rpc-*dependency would be unused andcargo shearwould reject it.Rebased onto current
main, preserving the serde (#31), tracing-journald (#32) and metrics (#34) bumps that landed while this was open.Validated with nightly formatting, strict Clippy, workspace tests and doctests, docs with warnings denied, and
cargo shear.Post-merge: cut tag
0.2.0, then bump consumers that want it.Resolves ENG-4723