chore: bump pyo3 version to 0.29 - #85
Merged
Merged
Conversation
cimandef
force-pushed
the
angel/bump_pyo3_version
branch
from
June 12, 2026 13:19
621cded to
9c609de
Compare
4 tasks
emooreatx
added a commit
to CIRISAI/CIRISEdge
that referenced
this pull request
Jun 12, 2026
#20 Reticulum-half (#92) * release(v2.2.0): Python surface re-exports — unblocks CIRISLens#18 §2 + #20 Reticulum-half The lens-core 1.0.1 cohabitation surface lands, but it can't construct Edge from Python because `python/ciris_edge/__init__.py` only re-exported `SUPPORTED_SCHEMA_VERSIONS + __version__`. The Rust crate + PyO3 bindings have been feature-complete since v2.1.0 (PyEdge + init_edge_runtime + transport_identity_pubkeys + engine all registered via #[pyclass] / #[pyfunction] in the pymodule), but the Python wrapper never surfaced them. This is a pure Python-wrapper fix: re-export the symbols the cdylib already registers. ## What ships `python/ciris_edge/__init__.py` now re-exports the full Phase 1 lens- cutover surface: ```python from .ciris_edge import ( SUPPORTED_SCHEMA_VERSIONS, DurableHandle, Edge, NetworkEventSubscription, ReplicationHandle, SubscriptionHandle, VerifiedFeedSubscription, __version__, init_edge_runtime, ) ``` Lens-core's `CIRISLens#18 §2 + #20` Reticulum-half pattern works as documented: ```python import ciris_edge, ciris_persist as cp engine = cp.Engine(dsn="postgres://lens:lens@localhost:5432/cirislens") edge = ciris_edge.init_edge_runtime(engine=engine, ...) pubkeys = edge.transport_identity_pubkeys() install_relay(edge) # lens-core 1.0.1's frozen hook ``` The docstring is updated with the full call shape; `__all__` carries the same eight names. ## Naming consistency — PyReplicationHandle → ReplicationHandle `PyReplicationHandle` shipped at v1.6.3 with no explicit `#[pyclass(name = "...")]` attribute, so its Python class name defaulted to the Rust struct name (`PyReplicationHandle`). The five other Edge-family pyclasses (Edge, DurableHandle, SubscriptionHandle, VerifiedFeedSubscription, NetworkEventSubscription) all carry `#[pyclass(name = "X", module = "ciris_edge")]` with the `Py` prefix stripped. ReplicationHandle joins the pattern. Safe: PyReplicationHandle was never re-exported through __init__.py in any prior release, so no Python consumer can be referencing `ciris_edge.PyReplicationHandle` today. Rust struct name unchanged (internal callers + `m.add_class::<PyReplicationHandle>()` still work). ## What's NOT in this cut The pyo3 0.28 → 0.29 lockstep + persist v5.5.3 → v6.0.0 currency (originally planned as v2.2.0) is deferred. The upstream pyo3 ecosystem isn't ready: - `pyo3-async-runtimes` latest is 0.28.0 (PyO3/pyo3-async-runtimes#85 open for 0.29 bump, not merged) - `pyo3-stub-gen` latest is 0.22.3 (no 0.29 work started upstream) Edge depends on both; can't move to pyo3 0.29 alone. Persist's ceiling-firewall (`ciris-persist<6` in our pyproject) keeps edge 2.x from accidentally pulling persist 6.0.0 in the meantime — Lens-core, agent, and edge stay coherent on the persist 5.x line until edge is g2g for pyo3 0.29. When the ecosystem catches up, the lockstep cuts as v3.0.0 (or v2.3.0 if minor is sufficient) with pyo3 0.29 + persist 6.0.0 together, per the persist team's coordinated-publish handoff doc. ## Substrate pin currency - `ciris-persist`: unchanged at v5.5.3 - `ciris-verify` family: unchanged at v5.1.0 - `leviculum`: unchanged at `ded96ee` ## Verification - 255 lib tests green - `cargo clippy --all-targets -- -D warnings` clean - `cargo fmt --check` clean Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(v2.2.0): pin time <0.3.48 — dodge rcgen ↔ time upstream conflict `time v0.3.48` published 2026-06-12 added a generic `Into<String>` impl that conflicts with `rcgen`'s blanket `impl<T: Into<String>> From<T> for OtherNameValue` / `DnValue`. Every edge PR (and downstream consumer) hits: ``` error[E0119]: conflicting implementations of trait `From<format_description::parse::format_item::HourBase>` for type `<HourBase as ModifierValue>::Type` --> rcgen-0.13.2/src/lib.rs:188:1 ``` Both rcgen 0.13.x and 0.14.x exhibit the same conflict — the fix has to come from rcgen upstream. Until then, edge pins `time = ">=0.3, <0.3.48"` as a direct dep to constrain transitive resolution. Edge doesn't use the `time` API surface — this is pure resolution control. Drop the constraint when rcgen ships a release that handles the new `Into<String>` impl (track at https://github.com/rustls/rcgen). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Collaborator
|
@cimandef I think 3.13t is deprecated; you can remove those from the github workflows matrix |
Contributor
|
@cimandef @kylebarron thank yall very much! |
emooreatx
added a commit
to CIRISAI/CIRISEdge
that referenced
this pull request
Jun 12, 2026
…(Tier-3 build-std) (#96) * release(v2.2.1): persist v5.5.3 → v5.5.5 + verify v5.1.0 → v5.1.3 + Win7-capable wheel (Tier-3 build-std) Coupled substrate + wheel upgrade: ## Substrate floor — security + Win7 capability - ciris-persist v5.5.3 → v5.5.5 (rust-postgres security floors + Win7 build-std fixes from CIRISPersist#205) - ciris-keyring + ciris-crypto v5.1.0 → v5.1.3 (CIRISVerify v5.1.3 ships the dirs 5→6 bump that drops windows-targets 0.48.5 — the Tier-3 LNK1181 link-fix v5.1.2 left open) ## pyproject ceiling — floor raise, ceiling held pyproject ciris-persist>=5.2.0,<6 → >=5.5.5,<6: - floor at >=5.5.5 picks up the rust-postgres security fix + Win7-capable wheel line (5.5.4+) - ceiling at <6 retains the pyo3-0.29 firewall — persist 6.0.0 already on PyPI but uses pyo3 0.29 internals; edge stays on pyo3 0.28 until upstream ecosystem (pyo3-async-runtimes#85 + pyo3-stub-gen 0.29) catches up ## Win7-capable wheel — CIRISPersist#205 mirror Edge's published win_amd64.whl now runs on Win7 SP1 + Server 2008 R2 in addition to Win10/11. Same wheel filename — pip platform-tag-matches on x86_64+windows only; the broadened ABI is invisible to consumers. CI's pyo3-wheel matrix Windows entry switches: - toolchain: stable → nightly (+ rust-src for build-std) - target: x86_64-pc-windows-msvc → x86_64-win7-windows-msvc (Tier-3) - env: CARGO_UNSTABLE_BUILD_STD=std,panic_abort so nightly compiles std from source, retaining Win7 fallback paths (keyed events, GetSystemTimeAsFileTime, RtlGenRandom) instead of stable ≥1.78's hard-imported Win8/Win10 APIs (WaitOnAddress, GetSystemTimePreciseAsFileTime, ProcessPrng) LNK1181 workaround: under -Zbuild-std the linker doesn't auto-discover the per-version windows.<N>.<M>.<P>.lib import libraries that windows-targets references inline. Pre-fetches the dep graph, then walks ~/.cargo/registry/src for every windows_x86_64_msvc-*/lib directory and prepends them to LIB. Same pattern persist v5.5.4 / v5.5.5 ships. Non-Windows runners stay on stable. Linux + darwin wheels unchanged. ## Verification (local) - 255 lib tests green - cargo clippy --all-targets -- -D warnings clean - cargo fmt --check clean Cargo.lock auto-updated: tokio-postgres v0.7.17 → v0.7.18 + transitive zeroize / wasip2 minor bumps. ## Holds + follow-ups - Tag held until persist v5.5.5 lands on PyPI - time = ">=0.3, <0.3.48" pin kept — rcgen ↔ time upstream conflict unresolved - pyo3 0.28 → 0.29 lockstep + persist v6.0.0 cuts as v3.0.0 once PyO3/pyo3-async-runtimes#85 merges Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(v2.2.1): scope Win7 env vars to the Windows shell branch The previous step-level `env:` block set `CARGO_BUILD_TARGET=''`, `RUSTUP_TOOLCHAIN=''`, `CARGO_UNSTABLE_BUILD_STD=''` on every runner including Linux + darwin. cargo treats empty `CARGO_BUILD_TARGET` as an explicit (invalid) target rather than as unset, so the Linux + darwin wheel builds failed with `error: target was empty` before maturin could even invoke cargo. The Windows env vars belong inside the Windows shell branch — `export` them after the `elif [ "${{ runner.os }}" = "Windows" ]` check so non-Windows runners never see them. Same shape persist v5.5.4's CIRISPersist#205 step uses. GitHub Actions step-level `env:` can't be `if:`-gated; conditional exports inside the script are the canonical pattern. Windows wheel build path unchanged (env vars take effect at the same point, the LNK1181 LIB augmentation walks immediately after). --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
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.
Closes #84