Skip to content

chore(deps): take the two upgrades the declared ranges already permit - #70

Merged
ciresnave merged 1 commit into
mainfrom
deps-to-latest
Sep 10, 2026
Merged

chore(deps): take the two upgrades the declared ranges already permit#70
ciresnave merged 1 commit into
mainfrom
deps-to-latest

Conversation

@ciresnave-bot

@ciresnave-bot ciresnave-bot commented Sep 10, 2026

Copy link
Copy Markdown
Collaborator

CireSnave's standing rule, verbatim: "I want all of my projects' dependencies on
their most recent versions at all times."

The measurement — all 24 direct crates.io dependencies

count crates
current 18
behind, range already permits 2 smallvec 1.15.2→1.16.0, uuid 1.24.0→1.26.1
behind, needs a manifest bump 4 safetensors sha2 sysinfo tokenizers
unknown 0

This PR takes the two needing no manifest change. The four that do are a
separate branch with real breakage risk — a zero-risk lockfile update should not
be held hostage to four API upgrades.

⚠️ The C2 gate caught it, which is the point of the gate

C2 FAILED: mlmf-core's transitive dependency set changed.
added:   ["smallvec v1.16.0"]
removed: ["smallvec v1.15.2"]
If intended, run: scripts/check-deps.sh --bless

Blessed, and the snapshot diff is exactly one line. A dependency change cannot
land here silently, and the gate names its own remedy.

Three methods, and how they were read

  1. a sparse-index read comparing Cargo.lock against the latest unyanked stable
  2. cargo-outdated 0.19.0 (newly installed, authorised)
  3. cargo update --dry-run — the operation itself

(1) and (2) name the same six. (3) confirms both move.

⚠️ Read the lockfile, not the manifest. uuid is declared 1.0 and locked at
1.24.0 against an available 1.26.1 — the caret range permits the upgrade, so a
manifest-only check reports compliance for exactly the case this rule targets.

⚠️ My first pass had two defects, both producing false "behind" rows

  • It ranked pre-releases as latest — smallvec 2.0.0-alpha.13 over 1.15.2.
  • It joined multiple locked versions into one string before comparing, so
    thiserror's "1.0.69,2.0.20" read as behind when our edge is current at 2.0.20.

Both fixed — and the fix changed smallvec's verdict in both directions: it is
genuinely behind, at 1.16.0, not at an alpha. Right verdict, wrong reason is not
a pass.

⚠️ And I nearly reported a disagreement that was my own misreading

cargo-outdated prints Compat: --- for uuid, which I first took as "no
semver-compatible upgrade exists"
— contradicting my own analysis. cargo update --dry-run moves it. The tools agreed; I had misread a column. Before recording
two instruments as disagreeing, check that you read both.

Separate finding, not addressed here

thiserror appears twice in Cargo.lock — 1.0.69 and 2.0.20. Our declared edge
is 2 and resolves to the latest; the 1.0.69 is a transitive duplicate someone else
pulls. Recorded rather than fixed.

Verification

cargo clippy --workspace --all-targets --all-features   exit 0
cargo fmt --all --check                                 exit 0
cargo test -p mlmf --lib                                106 passed
cargo test -p mlmf --doc                                29 passed
cargo test -p mlmf-core                                 132 passed, 18 binaries
cargo test -p mlmf-hf-layout                            exit 0

🤖 Generated with Claude Code

https://claude.ai/code/session_01MdVuiraXRfDHQ227cjBt51

Summary by Sourcery

Update the permitted smallvec and uuid dependency versions without changing manifest constraints.

Enhancements:

  • Update the lockfile to the latest versions permitted by the existing dependency ranges for smallvec and uuid.
  • Refresh the transitive dependency snapshot to reflect the intentional lockfile changes.

CireSnave's standing rule, verbatim: "I want all of my projects' dependencies on
their most recent versions at all times."

Measured across all 24 direct crates.io dependencies of this workspace:

  current                       18
  behind, range already permits   2   smallvec 1.15.2->1.16.0, uuid 1.24.0->1.26.1
  behind, needs a manifest bump   4   safetensors sha2 sysinfo tokenizers
  unknown                         0

This commit takes the two that need no manifest change. The four that do are a
separate piece of work with real breakage risk and are NOT bundled here -- a
zero-risk lockfile update should not be held hostage to four API upgrades.

## ⚠️ THE C2 GATE CAUGHT IT, WHICH IS THE POINT OF THE GATE

  C2 FAILED: mlmf-core's transitive dependency set changed.
  added:   ["smallvec v1.16.0"]
  removed: ["smallvec v1.15.2"]

Blessed via `scripts/check-deps.sh --bless`, and the snapshot diff is exactly one
line. A dependency change cannot land here silently, and the gate names its own
remedy rather than leaving the reader to find it.

## How the answer was reached, and the instrument's own defects

Two independent methods, and a third that settles them:

  1. a sparse-index read of every declared dep, comparing Cargo.lock against the
     latest UNYANKED STABLE release
  2. cargo-outdated 0.19.0 (newly installed, authorised for this)
  3. `cargo update --dry-run`, which is the operation itself

(1) and (2) name the SAME SIX crates. (3) confirms both move.

⚠️ READ THE LOCKFILE, NOT THE MANIFEST. `uuid` is declared `1.0` and locked at
1.24.0 against an available 1.26.1 -- the caret range PERMITS the upgrade, so a
manifest-only check reports compliance for exactly the case this rule targets.
Four of the six are the opposite shape: `0.7` genuinely excludes `0.8.0`.

⚠️ AND MY FIRST PASS HAD TWO DEFECTS, BOTH PRODUCING FALSE "BEHIND" ROWS:
it ranked PRE-RELEASES as latest (smallvec 2.0.0-alpha.13 over 1.15.2), and it
joined MULTIPLE locked versions into one string before comparing, so thiserror's
"1.0.69,2.0.20" read as behind when our declared edge is current at 2.0.20.

Fixed both, and the fix changed smallvec's verdict in BOTH directions: it is
genuinely behind, at 1.16.0, not at an alpha. RIGHT VERDICT, WRONG REASON is not
a pass -- the second reading is what makes the row actionable.

⚠️ AND I NEARLY REPORTED A DISAGREEMENT THAT WAS MY OWN MISREADING.
cargo-outdated prints `Compat: ---` for uuid, which I first took as "no
semver-compatible upgrade exists" -- contradicting my own analysis. `cargo update
--dry-run` moves it. The tools agreed; I had misread a column. Before recording
two instruments as disagreeing, check that you read both.

SEPARATE FINDING, not addressed here: `thiserror` appears TWICE in Cargo.lock,
1.0.69 and 2.0.20. Our declared edge is 2 and it resolves to the latest; the
1.0.69 is a transitive duplicate someone else pulls. Recorded rather than fixed.

VERIFIED:
  cargo clippy --workspace --all-targets --all-features   exit 0
  cargo fmt --all --check                                 exit 0
  cargo test -p mlmf --lib                                106 passed
  cargo test -p mlmf --doc                                29 passed
  cargo test -p mlmf-core                                 132 passed, 18 binaries
  cargo test -p mlmf-hf-layout                            exit 0

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MdVuiraXRfDHQ227cjBt51

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @ciresnave-bot, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 5 days and 11 hours by commenting @sourcery-ai review. Upgrade to get a review now.

@sourcery-ai

sourcery-ai Bot commented Sep 10, 2026

Copy link
Copy Markdown
Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

This PR performs a zero-manifest-change dependency refresh: Cargo.lock advances smallvec and uuid to the latest stable versions permitted by existing declarations, and the mlmf-core transitive-dependency snapshot is blessed for the resulting smallvec replacement. The implementation was cross-checked with three dependency-discovery/update methods and validated with formatting, clippy, and workspace/package tests.

File-Level Changes

Change Details Files
Refresh the lockfile for the two direct dependencies whose declared semver ranges already permit newer stable releases.
  • Update smallvec from 1.15.2 to 1.16.0.
  • Update uuid from 1.24.0 to 1.26.1 without changing its manifest declaration.
  • Verify the upgrades through sparse-index analysis, cargo-outdated, and cargo update --dry-run.
Cargo.lock
Bless the expected transitive dependency snapshot change so the dependency gate records the lockfile refresh explicitly.
  • Replace the locked smallvec version in the snapshot.
  • Keep the snapshot diff limited to the intentional smallvec upgrade.
crates/mlmf-core/tests/transitive-deps.snapshot

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results
Complexity 0
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@ciresnave
ciresnave merged commit b397e74 into main Sep 10, 2026
6 checks passed
@ciresnave
ciresnave deleted the deps-to-latest branch September 10, 2026 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants