Repository navigation
[ci][docker] build py3.14 ray image - #63237
elliot-barn wants to merge 24 commits into
Conversation
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
There was a problem hiding this comment.
Code Review
This pull request adds support for Python 3.14 across various CI and dependency configuration files. However, the review highlights that this addition is premature due to a lack of upstream support for Python 3.14 in critical libraries like PyTorch, TensorFlow, and JAX. Additionally, the newly added python/requirements_compiled_py3.14.txt contains invalid package versions and incorrect environment markers that will lead to immediate build failures and runtime errors.
| # dask | ||
| # distributed | ||
| # partd | ||
| torch==2.7.0 |
There was a problem hiding this comment.
This requirements file contains numerous non-existent or "future" package versions that are not available on PyPI or the specified indices. Examples include torch==2.7.0 (line 2373), numpy==2.3.2 (line 1267), and several packages with futuristic 2026.x versions (e.g., certifi==2026.4.22 on line 284). Additionally, the --find-links URL on line 2 points to a non-existent version. These errors will cause the Docker image build to fail immediately.
| - "3.11" | ||
| - "3.12" | ||
| - "3.13" | ||
| - "3.14" |
There was a problem hiding this comment.
Adding support for Python 3.14 is premature. Python 3.14 is currently in early alpha development and is not yet supported by critical upstream dependencies such as PyTorch, TensorFlow, and JAX. Furthermore, the Python ABI is not yet stable for this version. Adding it to the build matrix at this stage will result in broken CI builds and non-functional Docker images.
| # via msrestazure | ||
| adlfs==2026.4.0 | ||
| # via -r python/requirements/cloud-requirements.txt | ||
| aim==3.23.0 ; python_version < "3.12" |
There was a problem hiding this comment.
Many dependencies in this file (e.g., aim on line 33, array-record on line 120, configspace on line 387) include environment markers such as ; python_version < "3.12". Since this file is intended for Python 3.14, these dependencies will be skipped during installation, which will lead to missing packages and runtime failures in the Ray environment.
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
…oject/ray into elliot-barn-314-ray-image
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
…ot-barn-314-ray-image
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
|
This pull request has been automatically marked as stale because it has not had You can always ask for help on our discussion forum or Ray's public slack channel. If you'd like to keep this open, just leave any comment, and the stale label will be removed. |
|
Hi, is there anything blocking this, please? |
Was busy with other tasks but back to testing this before merging |
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d7b2d3f. Configure here.
| - "3.11" | ||
| - "3.12" | ||
| - "3.13" | ||
| - "3.14" |
There was a problem hiding this comment.
CUDA 13 py3.14 CI mismatch
Medium Severity
Python 3.14 is added to CUDA release and image-build matrices (including 13.0.0-cudnn), but dependency tooling explicitly excludes cp3.14 from the cu130 chain because cupy-cuda13x==13.6.0 has no cp314 wheel. Final CUDA images still run ray-image.Dockerfile, which installs that pin on cu13* platforms, so those new pipeline jobs are expected to fail at image build time.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit d7b2d3f. Configure here.
…mage resolving CPython 3.14.0 (#64857) ## Description ### Release smoke test Adds a `hello_world_py314` nightly smoke release test (aws variation only), mirroring the existing `hello_world_py313` entry: - `release/ray_release/schema.json` — add `"3.14"` to the `python` enum (release-test config validation rejects `python: "3.14"` without this). - `release/ray_release/config.py` — add `"3.14"` to the cpu/cu123 BYOD python allowlist (the parallel gate the release runner walks). - `release/release_tests.yaml` — new `hello_world_py314` test, nightly, `byod: {}`, same `hello_world_compute_config.yaml` as the other hello_world tests. The py3.14 `ray-anyscale` release-test images (cpu + cuda) are already built and published on master via `.buildkite/release/build.rayci.yml`, so no image plumbing is needed here. ### Base-image fix (what made the smoke test fail) The first run of this test failed with the JobSupervisor dying at job startup: `Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow`. Root cause: the py3.14 images ship **CPython 3.14.0**, which fatally crashes any Ray async actor running on a boost fiber stack (python/cpython#141944, fixed upstream in **3.14.2**). Why the images resolve 3.14.0: `docker/base-deps/Dockerfile` installs an exact `libffi=3.4.6` pin as a *separate* conda step after installing python. That second solve downgrades python to the only 3.14 build compatible with `libffi<3.5` — which is 3.14.0. (The stale wanda layer cache compounds this, but even a fresh rebuild today re-resolves 3.14.0 because of the pin.) Fix: replace the two-step install with a **single solve using a libffi floor** (`libffi>=3.4.6`, preserving the intent of the original pin — the 3.4.2/defaults-channel libffi was buggy). No per-version special casing; every python version resolves its newest patch release with a compatible libffi. Resolved versions today: py3.10→3.10.20 (libffi 3.7.0), py3.11→3.11.15, py3.12→3.12.13, py3.13→3.13.14 (libffi 3.5.2), py3.14→**3.14.6** (libffi 3.5.2). The Dockerfile change also busts the stale wanda cache. Note: #64772 (fiber stack-protection re-anchoring) is complementary, not a fix for this crash — its `PyUnstable_ThreadState_SetStackProtection` call only exists on 3.14.2+, so it no-ops on the 3.14.0 currently in the images. Once this lands, #64772 fixes the remaining per-task async-actor memory leak. ## Verification - Reproduced the crash: async-actor repro (`ray.get(A.remote().hi.remote())` with an `async def` method) dies in `rayproject/ray:nightly-py314-cpu` (CPython 3.14.0) with the exact failure signature from release-test job `prodjob_d4dctduzm3h6eu812vrrehiuzl`. - Verified the fix: the same unpatched nightly cp314 wheel on CPython 3.14.6 (`python:3.14-slim`) runs the repro successfully. - Verified the combined solve under miniforge 24.11.3-0 (same as the Dockerfile): dry-runs for python 3.10–3.14 all resolve (versions above), plus real installs with `ctypes` smoke tests on 3.10 (libffi 3.7.0) and 3.14.6 (libffi 3.5.2). - `python -m pytest -q release/ray_release/tests/test_config.py` — 23 passed; full collection validates (319 tests) including `hello_world_py314.aws`. ## Duplicate-work note #63237 contains an earlier version of the release-test config bundled with image-build plumbing that has since landed on master through other PRs. This PR carves out the remaining release-test config plus the base-image fix; #63237 can be closed or rebased down to the raylet fix. AI assistance (Claude Code) was used for this PR; all changes reviewed by the submitter. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…mage resolving CPython 3.14.0 (ray-project#64857) ## Description ### Release smoke test Adds a `hello_world_py314` nightly smoke release test (aws variation only), mirroring the existing `hello_world_py313` entry: - `release/ray_release/schema.json` — add `"3.14"` to the `python` enum (release-test config validation rejects `python: "3.14"` without this). - `release/ray_release/config.py` — add `"3.14"` to the cpu/cu123 BYOD python allowlist (the parallel gate the release runner walks). - `release/release_tests.yaml` — new `hello_world_py314` test, nightly, `byod: {}`, same `hello_world_compute_config.yaml` as the other hello_world tests. The py3.14 `ray-anyscale` release-test images (cpu + cuda) are already built and published on master via `.buildkite/release/build.rayci.yml`, so no image plumbing is needed here. ### Base-image fix (what made the smoke test fail) The first run of this test failed with the JobSupervisor dying at job startup: `Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow`. Root cause: the py3.14 images ship **CPython 3.14.0**, which fatally crashes any Ray async actor running on a boost fiber stack (python/cpython#141944, fixed upstream in **3.14.2**). Why the images resolve 3.14.0: `docker/base-deps/Dockerfile` installs an exact `libffi=3.4.6` pin as a *separate* conda step after installing python. That second solve downgrades python to the only 3.14 build compatible with `libffi<3.5` — which is 3.14.0. (The stale wanda layer cache compounds this, but even a fresh rebuild today re-resolves 3.14.0 because of the pin.) Fix: replace the two-step install with a **single solve using a libffi floor** (`libffi>=3.4.6`, preserving the intent of the original pin — the 3.4.2/defaults-channel libffi was buggy). No per-version special casing; every python version resolves its newest patch release with a compatible libffi. Resolved versions today: py3.10→3.10.20 (libffi 3.7.0), py3.11→3.11.15, py3.12→3.12.13, py3.13→3.13.14 (libffi 3.5.2), py3.14→**3.14.6** (libffi 3.5.2). The Dockerfile change also busts the stale wanda cache. Note: ray-project#64772 (fiber stack-protection re-anchoring) is complementary, not a fix for this crash — its `PyUnstable_ThreadState_SetStackProtection` call only exists on 3.14.2+, so it no-ops on the 3.14.0 currently in the images. Once this lands, ray-project#64772 fixes the remaining per-task async-actor memory leak. ## Verification - Reproduced the crash: async-actor repro (`ray.get(A.remote().hi.remote())` with an `async def` method) dies in `rayproject/ray:nightly-py314-cpu` (CPython 3.14.0) with the exact failure signature from release-test job `prodjob_d4dctduzm3h6eu812vrrehiuzl`. - Verified the fix: the same unpatched nightly cp314 wheel on CPython 3.14.6 (`python:3.14-slim`) runs the repro successfully. - Verified the combined solve under miniforge 24.11.3-0 (same as the Dockerfile): dry-runs for python 3.10–3.14 all resolve (versions above), plus real installs with `ctypes` smoke tests on 3.10 (libffi 3.7.0) and 3.14.6 (libffi 3.5.2). - `python -m pytest -q release/ray_release/tests/test_config.py` — 23 passed; full collection validates (319 tests) including `hello_world_py314.aws`. ## Duplicate-work note ray-project#63237 contains an earlier version of the release-test config bundled with image-build plumbing that has since landed on master through other PRs. This PR carves out the remaining release-test config plus the base-image fix; ray-project#63237 can be closed or rebased down to the raylet fix. AI assistance (Claude Code) was used for this PR; all changes reviewed by the submitter. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: 400Ping <jiekaichang@apache.org>
|
Hi, what's the status on this, please? Do I understand it correctly that ray package already supports Python 3.14, but we're just missing the docker image with py3.14? |


Adds CPython 3.14 as a supported target in Ray's CI/release infrastructure: wheel builder, image build pipeline, dependency locks, release-test config schema, and a
hello_world_py314smoke release test.Follow-up PR carries the
_raylet.soruntime fix that makes async actors actually work on cp3.14. This PR enables the build/test plumbing only; without the runtime PR landing first, any release test that exercises async actors will crash onJobSupervisor.Buildkite image build pipeline
.buildkite/_images.rayci.yml— addspy314entries to the base/cuda/slim image matrices so the image-matrix steps emit cp3.14 variants..buildkite/build.rayci.yml— image build + publish steps forray-py3.14andray-extra-py3.14..buildkite/linux_aarch64.rayci.yml— aarch64 base + image build + publish for cp3.14..buildkite/release/build.rayci.yml— anyscale release-test images (raycpubaseextra-testdeps,raycudabaseextra-testdeps,ray-anyscale-cpu-build,ray-anyscale-cuda-build,anyscalecpubuild,anyscalecudabuild) extended to cp3.14. This is what unblocks the prior CI errorStep dependencies not found: anyscalecpubuild--python314.ci/raydepsets/configs/rayimg.depsets.yaml— declares the cp3.14 depset for the ray image.Dependency locks (raydepsets)
New cp3.14 lock files generated via
raydepsets:Wheel builder + release-test config
ci/build/build_wheel.py—SUPPORTED_PYTHON_VERSIONSincludes"3.14", sopython ci/build/build_wheel.pyproduces cp314 wheels.release/ray_release/schema.json—"3.14"added to thepythonenum (without this, release-test config validation rejectspython: "3.14").release/ray_release/config.py—"3.14"added to the BYOD-type allowlist (parallel change to schema.json — both gates the release runner walks before accepting a test).Release smoke test
release/release_tests.yaml— addshello_world_py314(aws variation only, nightly cadence) that submits a trivialray.get(hello_world.remote())job. Uses the samehello_world_compute_config.yamlas the existinghello_worldtest, just pinned topython: "3.14"andanyscale_sdk_2026: true.Misc
docker/base-deps/Dockerfile— bumps libffi (cp3.14's_ctypesbuild needs the newer ABI).Verification
hello_world_py314release test passes against an image built from this branch