Add support for Python 3.13

[bdice]

Overview

Python 3.13 was released in October 2024. This issue tracks the work to add support for Python 3.13 to RAPIDS.

Prior work:

• Add support for Python 3.12 #40 added support for Python 3.12 (RAPIDS 24.10)
• Add support for Python 3.11 #3 added support for Python 3.11 (RAPIDS 24.04)

We now have excellent automation for this process thanks to @jameslamb. We can use rapids-reviser with this example script, which we should update to "add 3.13" instead of 3.12: https://github.com/rapidsai/rapids-reviser/tree/main/examples/add-python-3.12

Note: We would like to complete our work on C++ wheels (#33) before adding Python 3.13 support, to keep CI build time down.

When should we drop Python 3.10?

Typically RAPIDS has kept the matrix of supported Python minor versions to ~3 versions at a time. However, I don't think we should drop Python 3.10 at the same time (explained below).

SPEC 0 recommended dropping support for Python 3.10 in 2024Q4. Meanwhile, NEP 29 recommended dropping support for Python 3.10 as of Apr 04, 2025. SPEC 0 is more aggressive, and we have not yet passed the deadline for NEP 29. Because of this, we probably want to leave Python 3.10 for now. Previously we have had concerns about build / test times for a larger Python matrix. However, there have been other advances that help us: through the introduction of C++ wheels (#33), we have moved most of our build time into the C++ wheels, and the Python wheels are comparatively very fast. Eventually we still hope to use the Limited API to reduce the number of Python wheels we must build.

Tasks

Each section should be fully completed before moving to the next section.

CI images

• Add Python 3.13 CI images (ci-conda, ci-wheel, citestwheel) Add Python 3.13 ci-imgs#207

CI workflows

Branch Strategy:

• Create a branch on shared-workflows called python-3.13
• Add Python 3.13 to the build matrix on the python-3.13 branch
• Add Python 3.13 to the test matrix on the python-3.13 branch
  • When adjusting the test matrix, be aware of total GPU resource consumption. Build jobs are CPU only but test jobs require GPUs. We want to keep our GPU consumption the same (don't increase the test matrix size), by making it a bit sparser in its coverage. We have some rough guidelines for how to decide on the matrix entries to include.

The above tasks are handled by: rapidsai/shared-workflows#268

RAPIDS repositories

This list is intentionally in RAPIDS dependency order... they'll need to be completed in roughly that order.

Consult #40 for example PRs for any necessary work that isn't handled by rapids-reviser.

Updates for libraries

• pin Python version to 3.12 in devcontainers until all repos are migrated
• update pypi-wheel-scripts and manually build/publish cubinlinker and ptxcompiler wheels (https://github.com/rapidsai/pypi-wheel-scripts/pull/28)
• rapids-cmake feat: add Python 3.13 support rapids-cmake#834
• rmm Add support for Python 3.13 rmm#1851
• kvikio feat: add support for Python 3.13 kvikio#708
• pynvjitlink
• dask-cuda feat: add support for Python 3.13 dask-cuda#1475
• cudf Add support for Python 3.13 cudf#18648
• After cudf is merged
  • update dask-cuda test workflows to python-3.13 chore: set remaining workflows to python3.13 dask-cuda#1480
  • update ucxx test workflows to python-3.13 chore: set remaining workflows to python3.13 ucxx#409
  • update ucx-py test workflows to python-3.13 chore: set remaining workflows to python3.13 ucx-py#1131
• ucx-py Add support for Python 3.13 ucx-py#1129
• ucxx Add support for Python 3.13 ucxx#406
• raft Add support for Python 3.13 raft#2649
• cugraph Add support for Python 3.13 cugraph#5057
• cugraph-docs Add support for Python 3.13 cugraph-docs#113
• cugraph-gnn Add support for Python 3.13 cugraph-gnn#197
  • get a dgl build for Python 3.13 (currently blocking) (dgl being dropped for 25.08)
  • get the dgl tests removed or separated so we can run the rest on Python 3.13
    • chore: skip DGL tests on Python 3.13 cugraph-gnn#201
• nx-cugraph Add support for Python 3.13 nx-cugraph#132
• after all cugraph variants are in:
  • update remaining cugraph workflows to python-3.13
  • update remaining cugraph-gnn workflows to python-3.13
• cuml Add support for Python 3.13 cuml#6616
• cuvs Add support for Python 3.13 cuvs#874
• cuspatial
• cuxfilter Add support for Python 3.13 cuxfilter#682
• cucim Add support for Python 3.13 cucim#873
• private repos
• integration Add support for Python 3.13 integration#758
• cuopt https://github.com/rapidsai/cuopt/pull/2464
• cumlprims https://github.com/rapidsai/cumlprims_mg/pull/241
• rapidsmpf Add support for Python 3.13 rapidsmpf#262

For each repo,

1. Update .github/workflows/*.yaml to point to the python-3.13 branch of shared-workflows
2. Update dependencies.yaml to add support for Python 3.13.
3. Review any pyproject.toml files for necessary changes (classifiers, etc.)
4. Update docs (README, etc) that reference a single Python version to point to the latest (3.13).
5. Once CI passes, merge the PR.

Once all repos are migrated to the python-3.13 branch, the migration is complete. We merge python-3.13 into the development branch on shared-workflows and then open follow-up PRs to each repo to reset the branches to that development branch. This "reset" is simple and should be automated with rapids-reviser.

Post-migration

• Update the ci-imgs repo's latest configuration to use Python 3.13. (refactor: set Python 3.13 as latest ci-imgs#270)
• Update the docker repo's build and test matrices, and references in docs (refactor: add Python 3.13 support docker#755)
• Update the build matrix in pypi-wheel-scripts so that Python 3.13 wheels are uploaded
• Update rapidsai/dask-build-environment defunct
• update release selector in docs (feat: add Python 3.13 to selector and make it the new default docs#603)
• update all the repos to point at branch-25.06 on shared-workflows again
• move devcontainers Python version pin to Python 3.13 (refactor: make Python 3.13 the default devcontainers#512)
• (after updating all the repos) delete the python-3.13 branch in shared-workflows
• merge any remaining rapids-reviser changes

Notes:

The :latest image from ci-imgs is frequently used by CI jobs for building docs and testing notebooks. Be aware that issues may arise in those jobs.

[jameslamb]

Thanks for opening this! Adding one more useful link... the status of the Python 3.13 migration on conda-forge: https://conda-forge.org/status/migration/?name=python313

It'll be difficult to get too far down the RAPIDS dependency graph until that's further along. numba doesn't yet have Python 3.13 conda-forge packages (conda-forge/numba-feedstock#149), for example.

[bdice]

I updated our CI images and opened a few PRs to start the migration. It seems like there are a few subtasks we will need:

• Allow numba 0.61 at runtime (bump our upper bounds across RAPIDS and work out any incompatibilities)
• Get Python 3.13 wheel builds for nvcomp

Regardless, we can merge changes to pynvjitlink ahead of mainstream RAPIDS libraries, because it is independent of the RAPIDS shared-workflows CI job matrix.

[bdice]

Currently we are blocked by nvcomp wheels not supporting Python 3.13. There will be a future release of nvcomp with Python 3.13 support but we would like to support Python 3.13 sooner in RAPIDS.

One solution to this is to make our libkvikio C++ wheels vendor libnvcomp.so, which I think we did before we started using nvcomp wheels. We only need the nvcomp C++ library, we don't actually need the Python bindings in the nvcomp wheel, so this is a satisfactory solution for RAPIDS. We also discussed this idea offline with the nvcomp team and it should solve our needs. @jakirkham, would you have interest or bandwidth in working on that? I think it's a matter of changing some CMake options like USE_NVCOMP_RUNTIME_WHEEL so that we fetch the nvcomp tarball and vendor it into the libkvikio C++ wheel, rather than relying on the nvcomp wheel at runtime.

After making that change, we would also need to make the libcudf C++ wheel and kvikio Python wheel search for the nvcomp library being shipped in the libkvikio C++ wheel. This is probably either an RPATH change or a "library load" function call, as we have done for other RAPIDS libraries that depend on other RAPIDS C++ wheels or CUDA wheels.

[jakirkham]

I'm sorry Bradley. I don't have bandwidth to do this. Would suggest asking at the build-infra meeting

[mmccarty]

@jakirkham - Let's chat offline. We need to find a way forward.

[gforsyth]

This will probably also necessitate requesting a PyPI size exception for the libkvikio wheel, since libnvcomp.so is ~100 MB

[bdice]

@gforsyth I think it's smaller than that, perhaps when compressed. I see nvcomp wheels are ~46 MB and conda packages are ~33 MB or less. The existing libkvikio size is quite small (< 1 MB) so a size exception probably won't be needed for "libkvikio + vendored nvcomp".

[gforsyth]

Ok, I can take a crack at getting this done