deps(pyo3): bump from 0.26 to 0.28#29
Open
HaoZeke wants to merge 2 commits intometatensor:mainfrom
Open
Conversation
HaoZeke
added a commit
to HaoZeke/dlpack-fork
that referenced
this pull request
Apr 17, 2026
PR metatensor#29 surfaced the fact that pyo3 0.28 requires rustc 1.83, which broke the matrix `test (1.74)` job. Bumping dlpk's MSRV is not an option, and dropping the `pyo3` feature from the MSRV job would hide real breakage in that feature. Neither is acceptable. Instead, loosen the version requirement so either line of pyo3 is acceptable, and pin the 0.27 line only in the MSRV job: - `pyo3 = ">=0.27, <0.29"`: our migrated code path (`CapsuleName`, `pointer_checked`, etc.) is identical on 0.27.2 and 0.28.3 -- both added those APIs in 0.27, and 0.28 only deprecated older forms. So the same source compiles against either. - In tests.yml, the 1.74 job runs `cargo update -p pyo3* --precise 0.27.2` before `cargo test --all-features`. pyo3 0.27.2 keeps MSRV 1.74. Stable and nightly resolve to 0.28 naturally. Consumer impact: downstream crates on either pyo3 0.27 or 0.28 can now take dlpk as a dep without forcing a version conflict. This was the original motivation for the bump. Refs: metatensor-je9.
Downstream crates on pyo3 0.28 couldn't add dlpk as a dep, since cargo can't resolve two pyo3 versions in the same graph. The 0.27/0.28 capsule API moved: `PyCapsuleMethods::name()` now returns `Option<CapsuleName>` instead of `Option<&CStr>`. CapsuleName has no `PartialEq` or `Debug`, so name comparisons and error prints go through `as_cstr()`. `pointer()` is deprecated in favor of `pointer_checked(Some(name))`, which validates the name and returns `NonNull<c_void>`; this drops the manual null-check branches on the imports.
pyo3 0.28 requires rustc 1.83, which breaks the 1.74 matrix job. Skipping the pyo3 feature there would hide real breakage, and bumping dlpk's MSRV is not an option. Widen the version req to `>=0.27, <0.29` -- the migrated code uses CapsuleName and pointer_checked, both already in 0.27.2. On the 1.74 job, `cargo update -p pyo3* --precise 0.27.2` pins the older line; stable and nightly still resolve to 0.28.
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
1 participant
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.
PyO3 0.26 in the optional
pyo3feature prevented downstream crates on current PyO3 (0.28) from adding dlpk as a dependency: cargo cannot resolve two pyo3 major-minor versions in the same graph, and the two copies bring incompatible Python ABI symbols. Downgrading the consumer is a workable short-term patch but loses 0.27/0.28 ergonomics, so bump here instead.Mechanical migration against the 0.27/0.28 API:
PyCapsuleMethods::name()now returnsPyResult<Option<CapsuleName>>instead ofPyResult<Option<&CStr>>.CapsuleNamehas noPartialEqorDebug, so name comparisons and error messages go throughCapsuleName::as_cstr()(marked unsafe because the capsule name's lifetime is not statically tied to the capsule; we use the&CStronly for the immediate comparison and do not store it).PyCapsuleMethods::pointer()is deprecated since 0.27 in favor ofpointer_checked(Some(name)), which both validates the expected capsule name and returnsNonNull<c_void>. This removes the separate manual null-pointer branch inDLPackTensor::try_from(&Bound<PyCapsule>)and the hand-written null checks inPyDLPack::as_dltensor.No changes needed elsewhere:
#[pyclass],#[pymethods],Bound<'py, PyCapsule>,Py<PyCapsule>,Py<PyTuple>are all stable 0.26 -> 0.28.Verified: