Document `cuda-libraries`; use of cudatoolkit in CUDA 12+ world
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
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?
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.
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.
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.
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.