Skip to content

feat(pathfinder): centralize CUDA env var handling, prioritize CUDA_PATH over CUDA_HOME#1801

Draft
rwgk wants to merge 8 commits intoNVIDIA:mainfrom
rwgk:CUDA_PATH_CUDA_HOME_cleanup
Draft

feat(pathfinder): centralize CUDA env var handling, prioritize CUDA_PATH over CUDA_HOME#1801
rwgk wants to merge 8 commits intoNVIDIA:mainfrom
rwgk:CUDA_PATH_CUDA_HOME_cleanup

Conversation

@rwgk
Copy link
Collaborator

@rwgk rwgk commented Mar 20, 2026

Closes #1433

WIP-WIP-WIP

Current state: Squash-merge of PR #1519 rebased onto main. Untested (not even locally).

…d onto main.

Adds cuda.pathfinder._utils.env_var_constants with canonical search order,
enhances get_cuda_home_or_path() with robust path comparison and caching,
and updates documentation across all packages to reflect the new priority.

Co-authored-by: Rob Parolin <rparolin@nvidia.com>
Made-with: Cursor
@copy-pr-bot
Copy link
Contributor

copy-pr-bot bot commented Mar 20, 2026

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@rwgk
Copy link
Collaborator Author

rwgk commented Mar 20, 2026

Decision: drop os.pathsep splitting of CUDA_HOME/CUDA_PATH

Both cuda_bindings/build_hooks.py and cuda_core/build_hooks.py currently split the env var value on os.pathsep and iterate over a list of CUDA roots. After reviewing the codebase and the broader ecosystem, I'm removing this pattern. Rationale:

  • No real-world usage. The NVIDIA CTK installer (Windows), conda environments, pixi configs, and CMake's FindCUDAToolkit all set CUDA_PATH/CUDA_HOME to a single directory. There is no documented convention for pathsep-separated multi-path values.
  • Never tested. The two build_hooks.py files even disagreed on env var priority (CUDA_HOME > CUDA_PATH in bindings, CUDA_PATH > CUDA_HOME in core) — if anyone had used multi-path, that inconsistency would have surfaced.
  • Avoids premature complexity. Adding multi-path support to the new centralized get_cuda_home_or_path() (especially combined with the conflict-warning logic) would add design surface for a feature nobody uses today.

Both _get_cuda_paths() functions will be replaced with a plain get_cuda_home_or_path() call returning a single path. If a real multi-path use case surfaces later, we can add it with proper design at that point.


Related commit: 2164c33

Drop os.pathsep splitting of CUDA_PATH/CUDA_HOME in both build_hooks.py files.
Both functions now delegate to get_cuda_home_or_path() from cuda.pathfinder,
returning a single path.

See NVIDIA#1801 (comment)

Made-with: Cursor
@rwgk
Copy link
Collaborator Author

rwgk commented Mar 20, 2026

Decision: treat empty CUDA_PATH/CUDA_HOME as undefined

Rob's original implementation preserved empty strings (CUDA_PATH="") as valid return values from get_cuda_home_or_path(). I'm changing this so that empty strings are equivalent to the variable not being set. Rationale:

  • No valid use case. An empty string is not a valid filesystem path. Nobody intentionally sets CUDA_PATH="" to mean "the CUDA path is empty."
  • Fixes a subtle shadowing bug. With the old behavior, CUDA_PATH="" + CUDA_HOME=/usr/local/cuda would return "" (CUDA_PATH wins by priority), silently hiding the valid CUDA_HOME. Treating empty as undefined lets it correctly fall through.
  • Simplifies callers. All downstream consumers already do if not cuda_path: raise .... Returning "" just pushes the falsy check to every call site.
  • Matches convention. The standard os.environ.get("CUDA_PATH") idiom throughout the codebase has always treated empty and unset interchangeably (via if not value). This aligns with that expectation.

This addresses my review comment on Rob's PR: #1519 (comment)

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.

[FEA]: Improve handling of CUDA_HOME and CUDA_PATH in build across projects

1 participant