Skip to content

[WIP] feat: add CUDA management support to uv #14911

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AlpinDale
Copy link

@AlpinDale AlpinDale commented Jul 26, 2025

Summary

This PR adds CUDA version management and installation to uv. Users can install different CUDA versions using uv as they can python. Currently, it can be used like this:

$ uv cuda install 12.9.1
Installing CUDA 12.9.1
Extracting CUDA 12.9.1
Extraction complete
Successfully installed CUDA 12.9.1 to $HOME/.local/share/uv/cuda/cuda-12.9.1

To use this CUDA installation, run:
  uv cuda use 12.9.1
$ uv cuda use 12.9.1
Added CUDA environment to $HOME/.bashrc
CUDA 12.9.1 activated

To activate in new terminal sessions, either:
  - Restart your terminal
  - Run: source $HOME/.bashrc
$ source ~/.bashrc
$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Tue_May_27_02:21:03_PDT_2025
Cuda compilation tools, release 12.9, V12.9.86
Build cuda_12.9.r12.9/compiler.36037853_0

This implementation design is currently a WIP, and may change based on user and maintainer feedback. Ideally, we want integration with pyproject, but right now, it's shell-based and the user would need to source their shell again, like they would after a fresh uv installation.

Test Plan

No test units written yet. Will do after the design is approved.

@alexandreteles
Copy link

Any plans to support something like uv add cuda 12.9.1 or whatever would be the best interface for it? What about cudnn?

@AlpinDale
Copy link
Author

Yes, the interface is also WIP and I could switch to add if needed. I went with install because the python manager works like that too: uv python install 3.12 for example.

Also good call about cudnn, I'll have to see if I can include it here. It's usually not needed by default, so maybe it can be an optional flag.

@mstarodub
Copy link

It would be good to avoid all sorts of state, i.e.add instead of install (install is a misfeature of uv, imo).
Changing the shell rc file is a very bad idea and shouldn't be part of this - just setting the env vars for uv run would be better.

@zanieb
Copy link
Member

zanieb commented Jul 26, 2025

Thanks for the pull request! The idea is pretty cool. Just as a heads up, we won't accept a big interface change like this without internal consensus on a design, so I don't expect this to be merged in the near term.

As a brief high-level note, as @mstarodub is saying, the main part of this design that feels weird is the use experience. uv is attempting to avoid non-declarative state changes like that and requiring uv run would probably make more sense.

@alexandreteles
Copy link

@zanieb, what would be the best approach to get it merged quicker? Support it from add?

@zanieb
Copy link
Member

zanieb commented Jul 27, 2025

I don't think there's really a way to get it merged quickly, we are very careful about adding new features to uv as we'll need to maintain them in perpetuity. I think some consensus on what problems this solves is the first step.

@geofft
Copy link
Collaborator

geofft commented Jul 30, 2025

Do you have an example use case for this beyond nvcc --version, e.g., is there a Python dependency you want to build from source, or are you writing CUDA code in your own package that requires nvcc?

I want to play around with some alternate approaches for this and I'm trying to understand what sort of things expect which environment variables. For nvcc interactively you want $PATH, but I assume some things will need $CUDA_HOME and other variables and I'd like to understand/document exactly what needs them and why.

(FWIW, conda-forge/nvcc-feedstock and conda-forge/cuda-nvcc-feedstock both have activate hooks that set a whole lot of environment variables. The virtual environment ecosystem doesn't really support that, though, and as others mentioned, it's kind of distasteful. So I'd like some specific use cases to see what other options might work.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants