Ensure `cupy-core` can be installed in CPU-only envs

[leofang]

xref:

• https://github.com/conda-forge/staged-recipes/pull/26116#issuecomment-2068256761
• https://github.com/conda-forge/cupy-feedstock/issues/247#issuecomment-2068084682

This was the intended design (both in the upstream implementation and the new cupy-core packaging scheme). For some reason we overlooked it. Correction is made in this PR.

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

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 (recipe) and found it was in an excellent condition.

[leofang]

Setting this to draft as the alternative is to patch the repodata (and don't update the recipe until the next release or bug fix).

[hmaarrfk]

Thank you for taking an other stab at this.

I think it would help downstream projects if cupy-core could be a dependency, even if the package is empty, for systems where CUDA simply isn't supported:

• OSX amd64
• OSX arm64

[leofang]

I am still not sure why macOS is a problem. Here the relaxation makes sense, because the underlying assumption is "on the same system, if NVIDIA hardware and software are plugged in, the code will run." It's not the case for macOS, and if you are saying it is ok for "import cupy" to fail on Mac, why not just skip cupy-core when packaging for macOS?

run:
  - cupy-core  # [not osx]

We should not do anything that the upstream does not support, because it'd only be causing confusion for those who think "a package that's offered must be functional." It doesn't matter that we document it. Users don't read docs.

Also, have you tried MLX? (https://github.com/conda-forge/cupy-feedstock/pull/260#issuecomment-2041273852)

[leofang]

Setting this to draft as the alternative is to patch the repodata (and don't update the recipe until the next release or bug fix).

See https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/715

[hmaarrfk]

why not just skip cupy-core when packaging for macOS?

Because from a packaging standpoint, anything other than a noarch: python script "is more complicated". There are other usecases beyond recipes. environment.yml files don't have support for selectors. It becomes REALLY annoying to have environment-osx.yml, environment-linux.yml, environment-win.yml. Providing a single environment.yml file that "works to the best of your team's development platform" is really useful for sharing knowledge.

Again, I understand you aren't considering this usecase, but I expect it is quite common to have the following setup in many organizations:

• MAC local machine
• Linux + Nvidia GPU server

[leofang]

I see you're referring to known issues like (https://github.com/conda/conda/issues/8089, https://github.com/mamba-org/mamba/issues/1788). Unfortunately yes this is one of the few things that requirements.txt serves better.

However, it doesn't seem to be something that the cupy package needs to address? For example, you can

• build a custom meta package (as you originally planned to explore https://github.com/conda-forge/cupy-feedstock/pull/260#issuecomment-2041272961), or
• have a central place tracking and generating platform-specific environment.yml, or
• come up with a command line installation guide like what PyTorch and RAPIDS folks did

[leofang]

@jakirkham PTAL at this PR and also (https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/715), see the above discussion.

[hmaarrfk]

build a custom meta package (as you originally planned to explore https://github.com/conda-forge/cupy-feedstock/pull/260#issuecomment-2041272961), or

I understand. The maintenance burden of such packages cannot be ignored.

I'll keep these 3 options as others use and comment on their usecases more and more for cupy.

[leofang]

@conda-forge-admin, please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/cupy-feedstock/actions/runs/8850913003.

[github-actions[bot]]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!