You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Status update — v1.0 (branch v1.0, tip 39d3367) ships two mitigations:
numpy compatibility shim (cuvarbase/_skcuda_compat.py): restores the aliases scikit-cuda 0.5.3 references (np.typeDict, np.float/np.int/np.complex, np.sctypes) before any skcuda import, so cuvarbase installs and runs against numpy ≥ 1.24 / 2.x without hand-patching scikit-cuda.
Lazy module imports (PEP 562 __getattr__ in cuvarbase/__init__.py): import cuvarbase and the BLS / CE / PDM paths no longer touch scikit-cuda at all — only the Lomb-Scargle/NFFT modules (which need cuFFT) import it, and they apply the shim first.
This is verified in CI by a build-wheel → clean-venv → import smoke test that runs with only numpy+scipy installed.
Full replacement is still planned post-1.0: scikit-cuda is only used for cuFFT access, so the candidates are CuPy's cupy.cuda.cufft or a direct cuFFT binding alongside the existing PyCUDA streams. Keeping this issue open to track that.
v1.0 release note (deferral confirmed): the packed v1.0 release ships with scikit-cuda 0.5.3 still backing the Lomb-Scargle/NFFT cuFFT path. What shipped instead of the migration:
a numpy ≥ 1.24 compatibility shim (cuvarbase/_skcuda_compat.py) applied automatically before skcuda loads;
PEP 562 lazy imports, so import cuvarbase and the BLS/CE/PDM paths no longer touch skcuda at all.
The actual replacement (cupy.cuda.cufft or a direct cuFFT binding) remains committed post-1.0 as this issue describes; the v1.0 CHANGELOG carries the same statement under Known limitations and deferred work.
Hey @astrobatty , as usual thank you!! I made some decent progress on v1.0 in the 2 days that Fable 5 was available (you can surely tell the above was from Fable); I'm planning to wait until its back for a full audit and then manual review; v1.0 should be production ready soon!
Release triage for PR #69 (cuvarbase 1.0.1, source 6b6c48945160).
This issue is implemented in PR #69 and will close automatically when that PR merges into master. Keeping it open until the merge.
Lomb–Scargle/NFFT now use the in-house ctypes cuFFT binding. scikit-cuda is absent from runtime dependencies and imports, and the old NumPy compatibility shim is gone. The prior June comments describing replacement as deferred are superseded by this implementation; the original comments remain as history.
Activity
johnh2o2 commentedon Jun 11, 2026
Status update — v1.0 (branch
v1.0, tip 39d3367) ships two mitigations:cuvarbase/_skcuda_compat.py): restores the aliases scikit-cuda 0.5.3 references (np.typeDict,np.float/np.int/np.complex,np.sctypes) before anyskcudaimport, so cuvarbase installs and runs against numpy ≥ 1.24 / 2.x without hand-patching scikit-cuda.__getattr__incuvarbase/__init__.py):import cuvarbaseand the BLS / CE / PDM paths no longer touch scikit-cuda at all — only the Lomb-Scargle/NFFT modules (which need cuFFT) import it, and they apply the shim first.This is verified in CI by a build-wheel → clean-venv → import smoke test that runs with only numpy+scipy installed.
Full replacement is still planned post-1.0: scikit-cuda is only used for cuFFT access, so the candidates are CuPy's
cupy.cuda.cufftor a direct cuFFT binding alongside the existing PyCUDA streams. Keeping this issue open to track that.johnh2o2 commentedon Jun 12, 2026
v1.0 release note (deferral confirmed): the packed v1.0 release ships with scikit-cuda 0.5.3 still backing the Lomb-Scargle/NFFT cuFFT path. What shipped instead of the migration:
cuvarbase/_skcuda_compat.py) applied automatically before skcuda loads;import cuvarbaseand the BLS/CE/PDM paths no longer touch skcuda at all.The actual replacement (cupy.cuda.cufft or a direct cuFFT binding) remains committed post-1.0 as this issue describes; the v1.0 CHANGELOG carries the same statement under Known limitations and deferred work.
B2: in-house cuFFT ctypes binding, drop the scikit-cuda import (#63)
GPU batch 2 (A5000): validate B2/B3/C1; complete B2 by dropping sciki…
johnh2o2 commentedon Jun 18, 2026
Hey @astrobatty , as usual thank you!! I made some decent progress on v1.0 in the 2 days that Fable 5 was available (you can surely tell the above was from Fable); I'm planning to wait until its back for a full audit and then manual review; v1.0 should be production ready soon!
astrobatty commentedon Jun 19, 2026
Expect some changes in BLS, but otherwise sounds good!
johnh2o2 commentedon Sep 28, 2026
Release triage for PR #69 (cuvarbase 1.0.1, source
6b6c48945160).This issue is implemented in PR #69 and will close automatically when that PR merges into master. Keeping it open until the merge.
Lomb–Scargle/NFFT now use the in-house ctypes cuFFT binding. scikit-cuda is absent from runtime dependencies and imports, and the old NumPy compatibility shim is gone. The prior June comments describing replacement as deferred are superseded by this implementation; the original comments remain as history.
Evidence: direct lazy cuFFT binding · NFFT call-site migration · current package dependencies