This issue tracks dropping Python 3.9, following from the discussion on #40:

When should we drop Python 3.9?

Typically RAPIDS has kept the matrix of supported Python minor versions to 2 or 3 versions at a time. When adding Python 3.12, we should probably drop Python 3.9 as well.

SPEC 0 recommended dropping support for Python 3.9 in 2023Q4. Meanwhile, NEP 29 recommended dropping support for Python 3.9 as of Apr 05, 2024. Both of these deadlines have passed and several large Python libraries are now moving towards dropping Python 3.9, so it is probably reasonable to drop Python 3.9 around the same time that we add Python 3.12.

We are beyond the SPEC 0 date for dropping Python 3.9 now, and expect that RAPIDS dependencies will gradually drop support. We are exploring dropping Python 3.9 in RAPIDS 24.10.

Tasks:

• Announce deprecation: Dropping Support for Python v3.9 and adding Python 3.12 Support in Release v24.10 docs#528
• Drop Python 3.9 from shared-workflows: Drop Python 3.9 from workflows. shared-workflows#235
• For each repo, update Python requirements
  • Update matrix filters referencing Python 3.9
  • Edit dependencies.yaml to remove py: 3.9 sections like this
  • Edit dependencies.yaml to raise the fallback matrix's Python lower bound
  • Update CMake references like find_package(Python 3.9 ...)
  • Update pyproject.toml: requires-python and specifiers
  • Check for special cases, like ucxx's Python build matrix in conda_build_config.yaml
  • Update README, CONTRIBUTING, and docs as needed
  • grep for 3.9 to make sure nothing was missed!

Things to be careful about:

• Python version embedded in Jupyter notebook metadata (like this)
• avoid changing benchmarking results and the code to reproduce them
• pynvjitlink is used by more than just RAPIDS (like https://github.com/NVIDIA/nvmath-python), and uses its own CI matrix to support a broader range of versions than RAPIDS (link)... we may sometimes drop a Python version across RAPIDS but still support it in pynvjitlink
• generic tools like rapids-reviser, rapids-build-backend, rapids-metadata, etc. shouldn't have their floors bumped unless there's a compelling reason to do so... that'd make it harder to fix bugs in those tools that affect older releases