Document `cuda-libraries`; use of cudatoolkit in CUDA 12+ world

[h-vetinari]

I answered a question today that made me dig through some issues about the CUDA 12 bring-up again, and noticed that there's a convenience package cuda-libraries that I had never seen or heard of. Feedstock, staged-recipes PR

We should document this, plus how to set up the equivalent of the old cudatoolkit in a user environment (not recipe).

Xref: #1927

CC @conda-forge/cuda

[bdice]

The cuda metapackage is covered in the cuda feedstock docs for users and is the best way to get the entire CUDA Toolkit. The cuda-libraries is only a subset of runtime libraries and doesn’t have headers, compilers, etc. Users probably want cuda most of the time. https://github.com/conda-forge/cuda-feedstock/blob/main/recipe/doc/end_user_run_guide.md

We also have guides for other use cases, like CUDA package maintenance. See the README here: https://github.com/conda-forge/cuda-feedstock/tree/main/recipe

How can we make this information more widely known, or fill any gaps you see?

[h-vetinari]

How can we make this information more widely known, or fill any gaps you see?

I think the documentation on the cuda feedstock should move into the overall conda-forge docs. If it's unclear where that should go, you may be able to piggyback onto the new structure that's now emerging (xref #2633).

And those docs should answer obvious user stories like "how do I set up a full-fledged toolchain" resp. "how do I get a CUDA 12+ equivalent of what cudatoolkit used to be". Convenience outputs like cuda-libraries[-dev] can be part of that story.

[jaimergp]

I think the documentation on the cuda feedstock should move into the overall conda-forge docs.

I worry that the separate location leads to a friction in the contribution workflow that widens the information gap. I would be willing to compromise with a short summary page in the docs that links to the cuda-feedstock docs so it's easier to keep things in sync.

This also reveals a common issue we have with the documentation of technology specific content. There's precedent for things like MPI and BLAS, though, so I won't oppose if the folks that are responsible of those docs are willing to contribute it to the website repo.

[bdice]

I think the CUDA folks would be open to putting this into the conda-forge “main” docs! @vyasr and a few others wanted something in place around the time of CUDA 12.4/12.5. Things have stabilized with the drop of CUDA 11, so migrating docs to the most visible location is a good plan.

[vyasr]

As Bradley said, I wrote those docs around CUDA 12.5 so that we would have a clear resource to point to given how many major changes were happening at the time. Now that the dust has settled somewhat I would support adding some level of documentation in the main conda-forge docs.

I worry that the separate location leads to a friction in the contribution workflow that widens the information gap.

If this comment is expressing concern that moving the CUDA documentation into the main conda-forge docs will raise the barrier for maintainers of cuda-associated feedstocks to contribute updates to the documentation, yes I agree that is a potential point of concern and maybe a reason to do what @jaimergp suggests and have some basic CUDA docs in the conda-forge docs that link to the feedstock. (If this comment means something else then I'm afraid that I don't follow)

The one critical difference between MPI and BLAS is that those are APIs with multiple implementations, so there isn't a single canonical feedstock where you could document such things (I guess in some cases a metapackage or a mutex package exists, but I doubt anyone would go to look there). Conversely with CUDA there is a canonical location, so pointing to a feedstock rather than moving everything into the main conda-forge docs could be OK.