GH-48172: [Python] Add cp315 to build - #48191
Conversation
…til they ship 3.15 wheels.
|
|
|
@github-actions crossbow submit wheel-manylinux-2-28-cp315-cp315-amd64 |
|
Revision: 2d2a557 Submitted crossbow builds: ursacomputing/crossbow @ actions-c8d038a747
|
|
The build was destined for failure, because cp315 is not yet in the manylinux build. I'll reproduce locally and see if there's a graceful way to resolve, along with a clearer failure when PYTHON_ROOT is not found. The build failed oddly, but the earlier issue was that the detection of PYTHON_ROOT failed quietly:
A test should be added to verify PYTHON_ROOT is set / not empty and fail fast: arrow/ci/docker/python-wheel-manylinux.dockerfile Lines 110 to 111 in 2fb2f79 Build FailureCrossbow failed due to
caused by
|
|
Looking more closely, and considering the history of 3.13 and 3.14: This (nightlys) needs to wait manylinux adds cp315. The alternative is to add a cpython build step or use one of the other pre-built images, but this seems like more work than other projects are investing at this stage. Based on history of 3.13/3.14, this would be after b1 / 2026-05-05. |
|
@github-actions crossbow submit wheel-manylinux-2-28-cp315-cp315-amd64 |
|
|
Retrying/restarting this, now that 3.15b2 is out and available on ManyLinux. |
|
@github-actions crossbow submit wheel-manylinux-2-28-cp315-cp315-amd64 |
|
Revision: 6979e8c Submitted crossbow builds: ursacomputing/crossbow @ actions-60ca234412
|
|
I forgot this issue existed. I took a stab last week as seen here (only local testing): I added rustc and cargo to the images but libcst wasn't able to be built for Py3.15 due to PyO3 failures (no 3.15 support). Removing temporarily building libcst and the stubs build I had a green pass for tests. |
|
Yup, I see same libcst blocker, cleared by this PR: Instagram/LibCST#1454 (status update/edit: it's now merged, waiting on release, a local test of 1.8.7.dev built successfully) I got a good build against that PR: # requirements-wheel-build.txt
libcst @ git+https://github.com/AlexWaygood/LibCST.git@add-315; python_version >= "3.15"# pyproject.toml
"libcst>=1.8.6; python_version < '3.15'",
"libcst; python_version >= '3.15'", # fork doesn't build with the versionHappy to close in favor of your PR, but otherwise will just wait for that libcst PR to land, then update this to build against libcst main for 3.15 testing |
|
The Python 3.15 release candidate is now out, and Instagram/LibCST#1454 has been merged and released in LibCST v1.9.0: https://github.com/Instagram/LibCST/releases/tag/v1.9.0. And PyO3 should be ready for 3.15 as well now: https://github.com/PyO3/pyo3/releases/tag/v0.29.0. |
|
Could someone run this build? I bumped the libcst dependency, and it built locally. Thx: |
|
@github-actions crossbow submit wheel-manylinux-2-28-cp315-cp315-amd64 |
|
Revision: 9ed3dc3 Submitted crossbow builds: ursacomputing/crossbow @ actions-c6a3c83c52
|
github-actions
Bot
added
awaiting changes
|
@github-actions crossbow submit cp314 |
github-actions
Bot
added
awaiting merge
|
Revision: 1b9702d Submitted crossbow builds: ursacomputing/crossbow @ actions-c6ec9a86bf
|
|
Thanks @rok for kicking off the 3.14 wheels, the failures are related: |
|
re: macos errors on amd64: as of libcst 1.9.0, libcst is no longer building a wheel for the only intel builder (macos-13): Instagram/LibCST#1433
The reason macos worked on cp315 and failed on cp314 is:
Options:
|
|
Pinning libcst is fine imo |
|
Will do. I committed, but am running a test (on a crossbow fork) first. I'll ping when it's ready to run. This will unlock this PR, but does punt the question of what to do about the |
|
Could you run wheel-macos-monterey-cp314-cp314-amd64 and wheel-macos-monterey-cp315-cp315-amd64 again? Thank you |
|
@github-actions crossbow submit wheel-macos-monterey-cp314-cp314-amd64 wheel-macos-monterey-cp315-cp315-amd64 |
|
Revision: 189a10e Submitted crossbow builds: ursacomputing/crossbow @ actions-abd5189d00
|
|
@github-actions crossbow submit -g wheel |
|
Revision: 189a10e Submitted crossbow builds: ursacomputing/crossbow @ actions-a260277f36
|
raulcd
left a comment
raulcd
left a comment
There was a problem hiding this comment.
If no more comments, I'll merge this tomorrow. I will create an issue so we update to RC2 and the final release probably in time for 26.0.0.
|
FWIW, pandas should now have nightly wheels for python 3.15, so that might avoid having to skip that |
|
Sure, that'd be straightforward, something like this in requirements-test.txt and requirements-wheel-test.txt, and removing the PYARROW_TEST_PANDAS check. This PR or follow-on PR or rc2? |
|
@raulcd I can reenable pandas here or in a separate pr as a followup, whichever you prefer. I tested it locally on manylinux and it passed. |
|
Can you create an issue to follow it up? I'm happy doing it as a follow up |
|
Thanks for working on this @paultiq |
|
After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit ba5ca20. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 1 possible false positive for unstable benchmarks that are known to sometimes produce them. |
6 participants
Rationale for this change
Add Python 3.15 to the pyarrow nightly builds, so that issues can be detected early in the development cycles of both cpython & pyarrow.
Note:
CFFI andPandas doesn't have nightly 3.15 wheels, and are accordingly excluded.doesn't ship a 3.15 wheel, but is needed to build. It is building from source.What changes are included in this PR?
cffi/pandas for 3.15, as the wheels aren't yet available.2026-08-13 edit
Are these changes tested?
ninja-release-pythonpreset (not maximal)Are there any user-facing changes?
No functional changes, other than allowing the user to use Python 3.15.
Progress Notes (2026-08-15)
Each platform uses different sources for Python builds, each with different release schedules and paths:
/opt/python, so using the latest manylinux build is sufficient. 3.15 wasn't available until beta 1.python-free-threaded-wheel-musllinux-test-imports.dockerfile+-test-unittests.dockerfile: set the python_patch_version, and set build_date incompose.yaml.ci/scripts/install_python.sh. For early builds, needed to disable--only-binarysince at least one dependency needed to be built (no 3.15 wheels available yet)... only macos uses --only-binarychoco, seepython-wheel-windows-test-vs2022.dockerfileandpython-free-threaded-wheel-windows-test-vs2022.dockerfileFor 3.15.0rc1 builds, some care was needed because certain paths needed 3.15.0 and others needed the full 3.15.0rc1.