Add package to allow noarch python packages to depend on cupy

[hmaarrfk]

At this stage, i'm curious how it gets through the build process.

xref: conda-forge/cupy-feedstock#193

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/cupyifcudaavailable) and found some lint.

Here's what I've got...

For recipes/cupyifcudaavailable:

• Failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/cupyifcudaavailable) and found it was in an excellent condition.

[hmaarrfk]

PS. Note that mamba uses nvidia-smi to detect cuda and conda uses the presencence of libraries. If you don't have nvidia-smi installed it may appear as though mamba can't find __cuda see my comments in
mamba-org/mamba#3222

[hmaarrfk]

@jakirkham @leofang this is the package I have in mind to help me depend on cupy.

It allows downstream packages to just depend on "one thing" without creating cpu/cuda variants, or without creating osx/linux/windows variants.

[leofang]

Thanks @hmaarrfk for your relentless push. I finally understand what's missing in your use case, sorry it took me a while. I suggest

1. We close this PR. This is simply not a scalable approach if everyone wants a GPU package to be optionally installable on a CPU only env (assuming the package supports it).
2. We move cuda-version here from cupy-core's run to run_constrained (but leave cupy alone). This will ensure that cuda-version is used to distinguish CPU/GPU envs as per its design, and also ensure we don't install extra CUDA deps in a CPU-only env (because cupy-core should really be used here).

[hmaarrfk]

I agree that this is not a scalable approach. cupy is quite a unique package in that it targets a very specific hardware platform.

I'm happy to close this PR.

As i understand cupy does not target osx. so cupy-core would not be OK to have a dependency on noarch packages.

We can continue this discussion elsewhere more on the cupy feedstock.

[leofang]

Let's continue the discussion in conda-forge/cupy-feedstock#264 :)