Avoid building `cuvs` in `pip` devcontainer builds

[jcrist]

Per @bdice

If cuml is building cuvs from source in its devcontainers, we can probably change that and install packages nowadays.

In pip devcontainer builds we're seeing cuvs source being built. I tried to investigate why, but couldn't figure it out through the dependencies.yaml/cmake/... stack.

Example build log: https://github.com/NVIDIA/cuml/actions/runs/32778840561/job/97596127724

...
[10/5494] /usr/bin/sccache /usr/local/cuda/bin/nvcc -forward-unknown-to-host-compiler -ccbin=/usr/bin/g++ -DCCCL_DISABLE_PDL -DCUB_DISABLE_NAMESPACE_MAGIC -DCUB_IGNORE_NAMESPACE_MAGIC_ERROR -DRAFT_LOG_ACTIVE_LEVEL=RAPIDS_LOGGER_LOG_LEVEL_INFO -DRAFT_SYSTEM_LITTLE_ENDIAN=1 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST_DISABLE_ABI_NAMESPACE -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -DTHRUST_IGNORE_ABI_NAMESPACE_ERROR -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cuvs-src/cpp/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cuvs-src/cpp/src -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cuvs-src/cpp/../c/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/rmm-src/cpp/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/rmm-build/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cccl-src/lib/cmake/thrust/../../../thrust -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cccl-src/lib/cmake/libcudacxx/../../../libcudacxx/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cccl-src/lib/cmake/cub/../../../cub -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/nvtx3-src/c/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/rapids_logger-src/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/raft-src/cpp/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/raft-build/include -I/home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cuco-src/include -isystem /usr/local/cuda/targets/x86_64-linux/include -isystem /usr/local/cuda/targets/x86_64-linux/include/cccl -t=7 -O3 -DNDEBUG -std=c++20 "--generate-code=arch=compute_75,code=[lto_75]" -Xcompiler=-fPIC -Xfatbin=--compress-all --compress-mode=size -Xcompiler=-Wno-deprecated-declarations -DRAFT_HIDE_DEPRECATION_WARNINGS -Xcompiler=-Wall,-Werror,-Wno-error=deprecated-declarations,-Wno-reorder -Werror=all-warnings --expt-extended-lambda --expt-relaxed-constexpr -DCUDA_API_PER_THREAD_DEFAULT_STREAM -Xfatbin=-compress-all -Xcompiler=-fopenmp -MD -MT _deps/cuvs-build/CMakeFiles/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.dir/generated_kernels/ivf_flat/interleaved_scan/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.fatbin -MF _deps/cuvs-build/CMakeFiles/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.dir/generated_kernels/ivf_flat/interleaved_scan/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.fatbin.d -x cu -rdc=true -fatbin /home/coder/cuml/cpp/build/pip/cuda-13.3/release/_deps/cuvs-build/generated_kernels/ivf_flat/interleaved_scan/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.cu -o _deps/cuvs-build/CMakeFiles/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.dir/generated_kernels/ivf_flat/interleaved_scan/ivf_flat_interleaved_scan_capacity_128_ascending_data_i8_acc_i32_index_i64_kernel.fatbin
...

[jameslamb]

I'll look into this. Agree that for cuml's devcontainers in this repo, I'd expect to see cuVS being found from packages and not rebuilt from source.

[jameslamb]

So looking into a recent CUDA 13.3 pip devcontainer CI job, I see cuML reporting that it won't build cuVS, but then pulling its sources and building it (just confirming what you reported above).

...
-- CUML_CPP: Build and statically link CUVS libraries: OFF
...
-- Not cloning cuvs locally
-- CPM: Adding package cuvs@26.10.00 (main)
-- Fetching rapids-cmake from https://github.com/rapidsai/rapids-cmake/archive/refs/heads/main.ziparchive/refs/heads/main.zip
-- cuVS: Build cuVS unit-tests: OFF
-- cuVS: Build CPU only components: OFF
-- cuVS: Build ANN benchmarks: OFF
-- cuVS: Build only the shared library: OFF
-- cuVS: Enable detection of conda environment for dependencies: ON
-- cuVS: Disable deprecation warnings ON
-- cuVS: Disable OpenMP: OFF
-- cuVS: Enable kernel resource usage info: OFF
-- cuVS: Enable lineinfo in nvcc: OFF
-- cuVS: Enable nvtx markers: OFF
-- cuVS: Statically link the CUDA math libraries: OFF
-- cuVS: Build and statically link RAPIDS libraries: OFF
...
[39/5494] /usr/bin/sccache /usr/local/cuda/bin/nvcc ...  -o _deps/cuvs-build/CMakeFiles/cagra_setup_workspace_vpq_team_size_16_dataset_block_dim_128_8pq_2subd_data_i8_query_h_smem_e5m2_kernel.dir/generated_kernels/cagra/setup_workspace/cagra_setup_workspace_vpq_team_size_16_dataset_block_dim_128_8pq_2subd_data_i8_query_h_smem_e5m2_kernel.fatbin

(build link)

Compare that to a CUDA 13 libcuml wheel build from the same CI run, where packages are getting used:

-- Not cloning cuvs locally
...
-- CPM: Using local package cuvs@26.10.0

(build link)

Still looking...