[BUG] Missing Numba upper bound permits incompatible Numba 0.68 #940

Describe the bug

numba-cuda 0.30.4 declares only numba>=0.60.0, so dependency resolvers can install it with unsupported newer Numba releases. Numba 0.68.0 is incompatible with numba-cuda 0.30.4's disk-cache source stamps.

Numba 0.68 changed source freshness stamps in .nbi files from an (mtime, size) tuple to a SHA-256 digest of the source contents in numba/numba#10659. Numba-CUDA's vendored cache locator still produces the old tuple stamp.

CPU and CUDA dispatchers intentionally share one .nbi file for the same Python function. Each dispatcher therefore rejects the index written by the other as stale, starts from an empty overload mapping, and reuses .1.nbc, overwriting the other target's cached payload.

This was exposed by NVIDIA/cuda-python's nightly optional-dependency run after Numba 0.68.0 was released:

• Tracking comment: [CI failure] CI: Nightly optional-deps scheduled runs cuda-python#2748 (comment)
• Failing run: https://github.com/NVIDIA/cuda-python/actions/runs/36807221011
• Six identical failures across Linux x86-64, Linux aarch64, and Windows, with CUDA 12.9.1 and 13.4.2.

The two failures are:

CUDAAndCPUCachingTest.test_cpu_and_cuda_targets
AssertionError: 2 != 3 : [
  'cuda_and_cpu_caching_test_fodder.target_shared_assign-20.py312.1.nbc',
  'cuda_and_cpu_caching_test_fodder.target_shared_assign-20.py312.nbi',
]

CUDAAndCPUCachingTest.test_cpu_and_cuda_reuse
AssertionError: 0 != 1 : Counter()

The first assertion expects one shared index plus separate CPU and CUDA data files. Because CUDA treats CPU's index as stale, it overwrites .1.nbc instead of allocating .2.nbc. On re-import, CPU rejects CUDA's tuple-stamped index and recompiles, so no cache hit is recorded.

Steps/Code to reproduce bug

Install numba-cuda==0.30.4 with numba==0.68.0 and run:

pytest -v \
  numba_cuda/numba/cuda/tests/cudapy/test_caching.py \
  -k CUDAAndCPUCachingTest

The existing test requires a CUDA-capable runner. The underlying mismatch is also visible directly in the source-stamp implementations:

• Numba 0.68 uses a content digest:
  https://github.com/numba/numba/blob/0.68.0/numba/core/caching.py#L160-L191
• Numba-CUDA uses (st_mtime, st_size):
  https://github.com/NVIDIA/numba-cuda/blob/v0.30.4/numba_cuda/numba/cuda/core/caching.py#L416-L429

Expected behavior

Numba-CUDA package metadata should declare the supported Numba range so dependency resolvers do not create incompatible environments. Numba 0.66 is the latest release explicitly supported by numba-cuda 0.30.x, so the dependency should be numba>=0.60,<0.67 in both Python and conda package metadata.

Resolution

• Dependency-pin PR: [REVIEW] Pin compatibility bounds and skip unsupported IPC tests #942
• Superseded compatibility-code PR: [REVIEW] Fix shared cache source stamps with Numba 0.68 #941

PR #941 was closed in favor of the smaller maintenance-mode change in #942. Existing published releases such as numba-cuda 0.30.4 retain their original unbounded metadata, so downstream CI should also constrain numba<0.67 until a release containing the corrected metadata is available.

Environment details

• Environment: GitHub Actions; Linux x86-64, Linux aarch64, and Windows GPU runners
• Installation: pip wheels
• Python: 3.12.14
• numba-cuda: 0.30.4
• numba: 0.68.0
• llvmlite: 0.50.0
• numpy: 2.4.6

Additional context

The preceding nightly installed Numba 0.67.0 and passed, but 0.67 is not part of the explicitly supported range. Numba 0.68.0 was published later on September 30, and the October 1 nightly was the first run to resolve the incompatible version.