Make cpu or gpu variant default. about ucx-split-feedstock

[jakirkham]

I'm not sure whether a default makes sense in this case. Can see arguments either way. In one sense, it might make sense to make the CPU package default as people may not have access to GPUs. OTOH the bulk of people using this packages do have GPUs and intend to use it with GPUs; so, picking a default that hinders the bulk of users might be a poor choice.

More generally I'm less clear on what the best practice should be as far as a default for an arbitrary package that supports CPU and GPU use cases. Some packages will detect if a GPU is missing and run without it (even if the GPU components are built). In these cases there isn't a need to have a CPU package (unless users want a smaller install size). Other packages could be more performant when a GPU is available, but assuming a GPU is always around may be problematic.

TL;DR I think we need more time to build up our intuition about how different software handles CPU and GPU support and what users installing these packages expect.

[isuruf]

Without a default, conda solver might switch between CPU and GPU builds randomly.

[jakirkham]

The recommendation we have made to users is to install with a specific selection either CPU or GPU. With this selection made, it is part of the environment spec. So it will not switch.

It's true users may make the mistake of not including this selection and we may need to explain this to them. I'm more comfortable doing that than making a choice without sufficient information here.

[isuruf]

Adding run_constrained on __cuda for GPU builds will fix the issue of GPU build being installed when there's no GPU.

[jakirkham]

That is a separate discussion IMO. Though I think that should be added to cudatoolkit, which all Conda GPU packages (even outside of conda-forge) are depending on. ( conda/conda#9115 )