Skip to content

Keep arrow with the pyo3-arrow that can hold it - #29

Merged
martin-s-a merged 1 commit into
mainfrom
cap-arrow-to-pyo3-arrow
Oct 1, 2026
Merged

martin-s-a merged 1 commit into
mainfrom
cap-arrow-to-pyo3-arrow

Conversation

@martin-s-a

Copy link
Copy Markdown
Contributor

Closes the loop on #28, which cannot be made green.

pyo3-arrow exports no arrow of its own, so the RecordBatch that star::read_all builds and the one PyRecordBatch::new accepts are the same type only while both come from the same major. With arrow 60 in the graph and pyo3-arrow 0.19 holding arrow 59, src/lib.rs stops compiling, on every platform and every interpreter of the matrix:

error[E0631]: type mismatch in function arguments
note: expected function signature `fn(arrow::array::RecordBatch) -> _`

0.19 is the newest pyo3-arrow published, from June, so there is nothing to raise alongside arrow. This caps arrow below 60 until there is, with the reason written next to the cap so that whoever lifts it knows it goes in the same pull request that raises pyo3-arrow.

Only arrow is capped, deliberately. A pyo3-arrow release built against a newer arrow should open a pull request that fails CI — the signal to do both by hand — rather than freeze silently, which is the same line this config already takes with the split Python pins.

#28 can be closed once this lands; Renovate stops proposing 60 from then on.

🤖 Generated with Claude Code

Renovate has been offering arrow 60 since the 29th, and the pull request
cannot be made green. pyo3-arrow exports no arrow of its own, so the
RecordBatch star::read_all builds and the one PyRecordBatch::new accepts
are the same type only while both come from the same major. With arrow 60
in the graph and pyo3-arrow 0.19 holding arrow 59, lib.rs stops compiling:

    error[E0631]: type mismatch in function arguments
    note: expected function signature `fn(arrow::array::RecordBatch) -> _`

0.19 is the newest pyo3-arrow there is, from June, so there is nothing to
raise alongside it. arrow therefore stops below 60 until there is, and the
cap is lifted by whoever raises pyo3-arrow, in that same pull request.

Only arrow is capped. A pyo3-arrow built against a newer arrow should open
a pull request that fails CI, which is the signal to do both by hand,
rather than disappear into the dashboard.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
martin-s-a added a commit that referenced this pull request Oct 1, 2026
The constraint lives in renovate.json, where only Renovate reads it, and
a human raising pyo3-arrow by hand would meet it as a compiler error.

See #29.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@martin-s-a martin-s-a self-assigned this Oct 1, 2026
@martin-s-a martin-s-a added bug Something isn't working dependencies Pull requests that update a dependency file labels Oct 1, 2026
@martin-s-a
martin-s-a merged commit 020a34d into main Oct 1, 2026
18 checks passed
@martin-s-a
martin-s-a deleted the cap-arrow-to-pyo3-arrow branch October 1, 2026 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant