run-depend on `__cuda` for cuda variants

[wolfv]

So the cudatoolkit package only has a run_constrained on __cuda. That means, users without __cuda (e.g. an intel laptop without GPU) are currently still getting the CUDA-enabled package.
The CUDA-enabled package will work fine even with no GPU avaiable, but it will download roughly 0.5 - 1Gb of stuff that's not needed or useful in the CPU-only situation.

We discussed this briefly at the last conda-forge core meeting, and there are two options:

• make cudatoolkit run-depend (not constrain) on __cuda
• make the leaf packages like tensorflow depend on __cuda for the GPU variant

We decided to go with the latter. So I think it would be good to introduce a run dependency on __cuda (no version specifiers necessary) in a future build of tensorflow.

[h-vetinari]

Sounds good IMO; I added this to the things to do in the next build: #175

[h-vetinari]

Do we want this for libtensorflow{,_cc} outputs as well?

[wolfv]

I think so, yes, everything that has a cuda variant.

[h-vetinari]

Closed by #188

[isuruf]

cc @ngam

[ngam]

@wolfv + @conda-forge/core: Have we considered the case where people just want the extra 0.5--1 GB (e.g. they're on an HPC where compute nodes don't have internet access and they need to set up an env with cuda in it). This decision should be reconsidered as it may be breaking people's workflows and it goes against conventions of the maintainers of this package upstream (see next comment). This decision forces people to save 0.5--1 GB (let's be real: How worried are we about bloating conda environments by this additional 0.5--1 GB?!) and thus it makes no sense to me to institute this policy just for saving 0.5--1 GB, especially as it's making it nearly impossible (without override) to get an appropriate setup on an HPC.

Also have we considered how this breaks instructions and environment behaviors that people are used to? Many academic and government institutions (around the US at least; that's where I am based) point users to conda-forge and tensorflow to get a setup working, and if downloading tensorflow-gpu gets blocked because of the lack of __cuda on a login node, then that will likely render these instructions useless/confusing.

[ngam]

Also, note: the tf2.x convention seems to be that a package without a variant specification (e.g. "tensorflow") contains both the tensorflow-cpu and tensorflow-gpu compilation, whereas the tensorflow-cpu is the one lacking the gpu features. Can we just follow said convention?

For more:

• https://www.tensorflow.org/install/pip#tensorflow-2-packages-are-available
• compare https://pypi.org/project/tensorflow/#files with https://pypi.org/project/tensorflow-cpu/#files

[h-vetinari]

This decision is shortsighted and should be reconsidered.

Please dial down the rhethoric by at least two notches. I already voiced a very cautiously worded warning to that effect in #189, but you're not going to convince people by coming in an declaring the choices that people thought about in depth as shortsighted.

[ngam]

rhethoric

OMG, okay, I don't have time to discuss word choices, etc. here --- but a decision is, by definition, shortsighted if its consequences weren't anticipated (or considered); for example, in this case, this decision leads to breaking workflows on HPCs. I have not used the word in any "rhetorical" sense as an insult and I am not implying that people haven't thought about it a lot in other contexts. All I am saying is, the consequences for people working on HPCs don't seem to have been fully considered. I will reword my above comment to ensure my hasty word choices don't drag us into side conversations and don't distract from the main point. However, I am not here to really convince people --- this is nothing personal and I really won't professionally/personally benefit from any changes in the near future.

[h-vetinari]

To your (repeated) arguments:

• Bandwidth matters, especially for huge packages such as this one, and especially ones so popular. Ergo the default must be sane (and HPC is not the default).
• Installing GPU packages without an actual GPU is niche. There's the CUDA version selection and much more hanging on __cuda, and this dependence makes sense. For the niche case, the override is an acceptable trade-off, all things considered.
• Where instructions need updating, a PR to https://github.com/conda-forge/conda-forge.github.io would be great!
• The pypi package setup only concerns us very tangentially. pip doesn't have a useable method to distinguish between CPU/GPU, so package maintainers are forced to either name packages separately (tf previously) or bunch everything into one package (tf now), and live with the useless GPU-binary download for those with only a CPU.

I actually had another idea of how this might just possibly be salvaged, but I'm not going to throw that in only to take the heat for it from the other maintainers in a discussion you keep (unintentionally?) escalating.

[hmaarrfk]

Let's start this conversation again in a day or two when people have had a chance to think some of the points over.

[wolfv]

Sounds like a real special case to me.

If you really want gpu, ask for tensorflow-gpu. If that doesn't install because you don't have a GPU or GPU drivers, google a bit and figure out that you need to add the CONDA_CUDA_OVERRIDE env var to forcibly add the __cuda package :)