rename 'sklearn' conda dependency to 'scikit-learn'

[jameslamb]

#695 introduced a conda dependency on "sklearn". There is no sklearn... the package is called scikit-learn.

This fixes that.

Notes for Reviewers

How this fixes CI

On #738, @rhdong was facing the following problem. The conda-cpp-build jobs were producing packages with version 25.04.00a94:

BUILD START: ['libcuvs-25.04.00a94-cuda11_250303_g2ffe160_94.conda',
'libcuvs-static-25.04.00a94-cuda11_250303_g2ffe160_94.conda',
'libcuvs-examples-25.04.00a94-cuda11_250303_g2ffe160_94.conda',
'libcuvs-tests-25.04.00a94-cuda11_250303_g2ffe160_94.conda']

(logs link)

But at test time, they were getting 25.05.00a84:

...
libcuvs                   25.04.00a84     cuda11_250224_ga1e0cc0_84    rapidsai-nightly

(logs link)

It looks like this sklearn dependency was the root cause, as explained in #743 (comment)

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[jameslamb]

/ok to test

[jameslamb]

aha!! Think this would explain it!

LibMambaUnsatisfiableError: Encountered problems while solving:
  - nothing provides sklearn >=1.5 needed by cuvs-bench-25.04.00a95-cuda11_py310_250303_g6ba6666_95

Could not solve for environment specs
The following packages are incompatible
├─ cuvs-bench 25.4.*,>=0.0.0a0  is installable with the potential options
│  ├─ cuvs-bench [25.04.00a86|25.04.00a87|...|25.04.00a95] would require
│  │  └─ sklearn >=1.5 , which does not exist (perhaps a missing channel);
│  ├─ cuvs-bench 25.04.00a84 would require
│  │  └─ cuvs 25.04.00a84.*  with the potential options
│  │     ├─ cuvs 25.04.00a84 would require
│  │     │  └─ libcuvs 25.04.00a84.* , which can be installed;
│  │     ├─ cuvs 25.04.00a84 would require
│  │     │  └─ python >=3.11,<3.12.0a0 , which can be installed;
│  │     └─ cuvs 25.04.00a[84](https://github.com/rapidsai/cuvs/actions/runs/13640201652/job/38132073495?pr=743#step:9:85) would require
│  │        └─ python >=3.12,<3.13.0a0 , which can be installed;
│  ├─ cuvs-bench 25.04.00a84 would require
│  │  ├─ python >=3.11,<3.12.0a0 , which can be installed;
│  │  └─ python_abi 3.11.* *_cp311, which can be installed;
│  └─ cuvs-bench 25.04.00a84 would require
│     └─ python_abi 3.12.* *_cp312, which can be installed;
├─ libcuvs 25.4.*,>=25.4.00a[91](https://github.com/rapidsai/cuvs/actions/runs/13640201652/job/38132073495?pr=743#step:9:92)  is not installable because it conflicts with any installable versions previously reported;
└─ python 3.10**  is not installable because there are no viable options
   ├─ python 3.10.8 conflicts with any installable versions previously reported;
   └─ python [3.10.0|3.10.1|...|3.10.9] would require
      └─ python_abi 3.10.* *_cp310, which conflicts with any installable versions previously reported.

(build link)

There is no package called sklearn... it's called scikit-learn. So the solver is falling back to the last package before #695 added an sklearn dependency.

[jameslamb]

/ok to test

[jameslamb]

Looks like this worked... conda is now installing the package built in this same CI run.

libcuvs                   25.04.00a92     cuda11_250303_g7fbe487_92    file:///tmp/cpp_channel

(build link)

[betatim]

For my curiosity/education: is there a way to tell the tool used to build conda packages that if one of the dependencies doesn't exist, it should error/warn (very loudly)? It seems hard to imagine a situation where I add a dependency to my package's dependencies list and I am Ok with it not existing.

Basically, I was wondering how it happened that it was hard to spot that sklearn as a dependency was a mistake in #695

(For PyPI there is a sklearn that will error if you install it. I guess for conda-forge no one has bothered to create a similar package, also not clear if it would be smart)

[jameslamb]

It seems hard to imagine a situation where I add a dependency to my package's dependencies list and I am Ok with it not existing.

"not existing" means "not found in the channels conda is configured to look at during the build", not "could never be found in other channels".

There are cases where that's helpful. For example, cugraph-dgl has a runtime (note: not build-time) dependency on dgl.

https://github.com/rapidsai/cugraph-gnn/blob/8074120bd99992aa033632871c039136bf49d26c/conda/recipes/cugraph-dgl/meta.yaml#L28

The CUDA dgl packages are distributed via the dglteam channel (not conda-forge), and we don't make that channel available at build time in CI. That makes builds a bit faster.

is there a way to tell the tool used to build conda packages that if one of the dependencies doesn't exist, it should error/warn (very loudly)?

This is one of many failure modes that are intended to be caught by the test: section of the conda recipe, which will do things like run python -c "import {module}". Something like that would have had a good chance of catching this mistake.

And we have that in many recipes across RAPIDS...

cuvs/conda/recipes/cuvs/meta.yaml

Lines 72 to 76 in af81a61

	tests:
	requirements:
	- cuda-version ={{ cuda_version }}
	imports:
	- cuvs

... but skip it by passing --no-test ...

cuvs/ci/build_python.sh

Lines 28 to 31 in af81a61

	rapids-conda-retry build \
	--no-test \
	--channel "${CPP_CHANNEL}" \
	conda/recipes/cuvs

... because conda builds run on CPU-only runners, and so many RAPIDS packages cannot be import'd without a GPU in the environment.

The most reliable way to catch problems like this given those constraints is to force conda to install exactly the package built in CI at test-time. If we had that, the builds in #695 would have failed with a big loud solver error like #743 (comment)

You may want to follow conversation about that at these places:

• Ensure cached packages installed in CI test phase build-planning#14 (comment)
• Switch to using strict channel priority during RAPIDS builds build-planning#84

[bdice]

Thanks, this fix makes sense. Strict channel priority will help us a lot...

[jameslamb]

/merge