Repository navigation
Conversation
Same bumps as #2858 (pyo3 0.29->0.30, syn 2->3 in the random-fs fixture, hyperlight 0.259->0.262, wit-bindgen 0.62->0.63) plus the companions the 0.30 jump requires: jiter 0.17->0.18 (its required pyo3 dep moves to ^0.30.1) and pyo3-async-runtimes 0.29->0.30. Without them the two pyo3 majors collide on links=pyo3-python and resolution fails, which sank #2858. pyo3 0.30 makes skip_from_py_object the default and deprecates the option (deny-warnings clean): removed the 8 now-no-op occurrences. No extraction behavior change: nothing extracts these pyclasses via FromPyObject (workspace check is clean). Vet: exemption bumps for the new versions (pyo3 set, jiter), matching existing cover. Supersedes #2858.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
bashkit | 4a19cfc | Commit Preview URL Branch Preview URL |
Nov 07 2026, 02:02 PM |
![bashkit-pr-reviewer[bot]](https://avatars.githubusercontent.com/u/249470897?s=60&v=4){kind=small}
There was a problem hiding this comment.
Dependency unification looks correct: version bumps are consistent across workspaces, cargo-vet exemptions match the new versions, and the skip_from_py_object removals are behavior-preserving under PyO3 0.30 (verified no extract::<...>() of those types; only BuiltinResult is extracted and it keeps from_py_object). One stale-doc follow-up below.
| itertools = { version = "0.14.0" } | ||
| itoa = { version = "1" } | ||
| jiter = { version = "0.17.0", features = ["num-bigint"] } | ||
| jiter = { version = "0.18.0", features = ["num-bigint"] } |
There was a problem hiding this comment.
[P2] Knowledge now stale: knowledge/operations/dependencies.md:90-91 still says "Monty 1.4 uses published jiter 0.17 with pyo3 0.29", but this PR moves the tree to jiter 0.18 / pyo3 0.30 (this file's jiter = "0.18.0" line is the evidence). Per AGENTS.md (update knowledge in the same change when durable facts change), update that sentence to jiter 0.18 with pyo3 0.30 in this PR.
Review summary (head
|
The fork-drift check rejected jiter 0.18 in bashkit-monty because upstream Monty 1.4.0 pins 0.17. #2876 made a marked version divergence legal, so the line now carries its reason: upstream's 0.17 declares pyo3 ^0.29.2, the Python binding is on 0.30, and the two collide on links=pyo3-python, so cargo cannot resolve the workspace at all. jiter 0.18 moves its pyo3 requirement to ^0.30.1 and unifies the graph on one major; 0.19 exists but is not needed. Cargo.lock now holds a single pyo3 (0.30.1), jiter 0.18.0 and pyo3-async-runtimes 0.30.0. Claude-Session: https://claude.ai/code/session_01Wy7MByvAMwapenBYpmq9HN
What changed
Same bumps as #2858 (pyo3 0.29->0.30, syn 2->3 in the random-fs fixture, hyperlight 0.259->0.262, wit-bindgen 0.62->0.63) plus the companions the jump requires: jiter 0.17->0.18 and pyo3-async-runtimes 0.29->0.30. Supersedes #2858.
Why
#2858 cannot land: pyo3 0.30 and jiter 0.17's pyo3 0.29 collide on links=pyo3-python, so resolution fails in every rust job. jiter 0.18 moves its required pyo3 dep to ^0.30.1 and pyo3-async-runtimes 0.30 tracks pyo3 0.30, unifying the graph on one major.
Before / After
Before (#2858): failed to select a version for pyo3 (links conflict 0.29.x vs 0.30.1) in Lint and everything downstream.
After: cargo check --workspace --all-targets clean, zero warnings; clippy -D warnings clean on the touched crates; monty lib tests 49 passed.
pyo3 0.30 notes: skip_from_py_object is now the default and the option is deprecated, so the 8 occurrences are removed (behavior-preserving; nothing extracts these pyclasses via FromPyObject or the workspace check would fail). Direct cargo build of the cdylib still needs maturin for libpython linking (pre-existing); the maturin/pytest matrix here is the real validation.
Vet: exemption bumps for the new versions (pyo3 set, jiter), same trust already granted.
Risk
Checklist
Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.