switch from 'cuda-python' to specific components (e.g. 'cuda-bindings')#153
Conversation
jameslamb
added
DO NOT MERGE
|
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. |
|
/ok to test |
jameslamb
changed the title
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR replaces the Changescuda-python to cuda-bindings migration
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@conda/environments/all_cuda-129_arch-aarch64.yaml`:
- Line 13: The CUDA version pin is too broad and can allow 13.0 prereleases in
conda solves. Update the CUDA constraint in the relevant repeated pin locations,
including the environment YAML, recipe, and dependencies YAML, to keep the upper
bound at 13.0a0 rather than 13.0; use the existing cuda-bindings pin as the
reference point for the exact version spec format.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 236b84e0-3714-45a7-95ee-2c5eb9547d2e
📒 Files selected for processing (7)
conda/environments/all_cuda-129_arch-aarch64.yamlconda/environments/all_cuda-129_arch-x86_64.yamlconda/environments/all_cuda-133_arch-aarch64.yamlconda/environments/all_cuda-133_arch-x86_64.yamlconda/recipes/nvforest/recipe.yamldependencies.yamlpython/nvforest/pyproject.toml
| - ccache | ||
| - click | ||
| - cmake>=4.0 | ||
| - cuda-bindings>=12.9.2,<13.0 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if cuda-bindings has published any prerelease/alpha conda builds
# for the CUDA 13 series that a bare "<13.0" bound could match.Repository: rapidsai/nvforest
Length of output: 155
🏁 Script executed:
rg -n "cuda-bindings|cuda-python|<13\.0a0|<13\.0" conda recipe.yaml dependencies.yaml .Repository: rapidsai/nvforest
Length of output: 2173
🏁 Script executed:
sed -n '396,452p' dependencies.yaml && printf '\n---\n' && sed -n '82,110p' conda/recipes/nvforest/recipe.yaml && printf '\n---\n' && sed -n '1,24p' conda/environments/all_cuda-129_arch-aarch64.yamlRepository: rapidsai/nvforest
Length of output: 3304
🌐 Web query:
conda version specifier <13.0 prerelease 13.0.0a0 conda solver semantics
💡 Result:
In conda, the version specifier <13.0 does not include prerelease versions such as 13.0.0a0 because conda treats prerelease versions as strictly less than their corresponding release versions [1][2]. Consequently, a specifier like <13.0 matches versions up to, but not including, the first prerelease version that would otherwise be considered a "starting point" for the 13.0 release [1]. To specifically exclude all 13.0-series prereleases while still allowing 12.x versions, the specifier <13.0.0a0 is often used [1]. This ensures the constraint terminates precisely at the start of the 13.0 series, effectively excluding 13.0.0a0 and any subsequent 13.0 prereleases [1]. Regarding solver semantics: - Conda's default behavior is to allow prereleases when they are requested or available [3][4]. - There is a configurable prerelease_behavior setting (available in more recent conda versions) that can be set to allow, exclude, or limit prereleases [3]. The limit mode is designed to align with PEP 440, which generally excludes prereleases unless they are already present or are the only way to satisfy the specifier [3][4]. - Because conda's version comparison logic explicitly places prereleases (like 'a', 'b', 'rc') as smaller than the final release version (e.g., 13.0.0a0 < 13.0) [5][6][7], a simple <13.0 constraint is often interpreted by users as "everything below 13.0," but in practice, it may leave a gap if the solver interprets the boundary relative to the specific version ordering [1][2]. Using the trailing 'a0' suffix in the constraint explicitly defines the boundary at the very first prerelease of the target version [1].
Citations:
- 1: conda version matching breaks on prerelease package version conda/conda#9051
- 2: https://docs.conda.io/projects/conda/en/stable/user-guide/concepts/pkg-specs.html
- 3: PEP 440 prerelease handling conda/conda#11797
- 4: Exclude Pre-Releases conda/conda#5021
- 5: https://docs.conda.io/projects/conda/en/stable/dev-guide/api/conda/models/version/index.html
- 6: https://github.com/conda/conda/blob/main/conda/models/version.py
- 7: https://github.com/conda/conda/blob/4.2.13/conda/version.py
🌐 Web query:
site:docs.conda.io conda package specs prerelease <13.0 a0 version ordering
💡 Result:
In Conda's versioning system, pre-release versions—such as those denoted by letters like 'a' (alpha), 'b' (beta), or 'rc' (release candidate)—are consistently considered less than their corresponding release versions [1][2][3]. Regarding version ordering for specifications like <13.0a0, the following rules apply: 1. Canonical Ordering: Conda's version comparison algorithm (implemented by the VersionOrder class) parses version strings by splitting them into components (delimited by dots and underscores) [1][4][3]. These components are then parsed into runs of numerals and non-numerals [2][3]. 2. Alpha/Pre-release Handling: When a component begins with a letter (like 'a' in '13.0a0'), Conda implicitly inserts a fill-value of 0 to keep numerical and string components in phase [1][2][3]. Consequently, '13.0a0' is treated equivalently to '13.0.0a0' [1][3]. 3. Ordering Logic: Within the comparison logic: - Integers are compared numerically [2][3]. - Strings are compared lexicographically (case-insensitive) [1][2][3]. - Non-release (pre-release) strings are generally considered smaller than integers [2][3]. 4. Result of <13.0a0: Because Conda defines pre-release versions as less than release versions, a constraint of <13.0a0 will include earlier pre-release versions (e.g., 12.9a1, 13.0a0) but exclude the final 13.0 release, as 13.0 is greater than 13.0a0 [1][2]. For predictable results, it is recommended to maintain a consistent versioning scheme and ensure components are correctly aligned [1][2][3]. If you encounter compatibility issues with specific naming conventions (such as OpenSSL-style versions), appending an underscore (e.g., 1.0.1_) can sometimes force the intended evaluation [2][3].
Citations:
- 1: https://docs.conda.io/projects/conda/en/23.3.x/user-guide/concepts/pkg-specs.html
- 2: https://docs.conda.io/projects/conda/en/24.4.x/dev-guide/api/conda/models/version/index.html
- 3: https://docs.conda.io/projects/conda/en/stable/dev-guide/api/conda/models/version/index.html
- 4: https://docs.conda.io/projects/conda/en/22.11.x/user-guide/concepts/pkg-specs.html
🌐 Web query:
conda prerelease specifier "<13.0" "<13.0a0" package specs default solver behavior
💡 Result:
In conda, version comparisons are governed by specific ordering rules where prerelease versions are considered less than their corresponding release versions [1][2]. When using the package specifiers "<13.0" and "<13.0a0", the solver behavior differs due to how these specifiers interact with prerelease versions [1][3]. Specifier "<13.0" This specifier excludes version 13.0 and any version greater than or equal to 13.0 [1]. Because conda considers prereleases (e.g., 13.0a1, 13.0b1) to be less than the release version 13.0, the specifier "<13.0" will match and allow prerelease versions of 13.0 (such as 13.0a1) [1][3]. Specifier "<13.0a0" This specifier is more restrictive. Since 13.0a0 is a prerelease version, "<13.0a0" excludes 13.0a0 and any versions greater than or equal to it, including the final 13.0 release and all other 13.0 prereleases (as they are generally ordered after 13.0a0) [1][3]. This effectively forces the solver to look for versions strictly lower than the 13.0 prerelease series. Solver Behavior and Configuration Conda's default solver behavior for prereleases is governed by the configuration setting prerelease_behavior [4]. - Default: The default behavior is to treat prereleases the same as release versions, meaning they are considered by the solver if they satisfy the version specifier [4]. - Other modes: Conda also supports exclude (which ignores prereleases entirely) and limit (which follows PEP 440 recommendations, allowing prereleases only if they are already in the environment or are the only way to satisfy the spec) [4][5]. Additionally, users can use prerelease_allowed_packages to prevent specific packages from being treated as prereleases, which is useful for packages with non-standard versioning schemes that might otherwise trigger incorrect prerelease handling [4].
Citations:
- 1: https://docs.conda.io/projects/conda/en/23.3.x/user-guide/concepts/pkg-specs.html
- 2: https://docs.conda.io/projects/conda/en/stable/user-guide/concepts/pkg-specs.html
- 3: https://docs.conda.io/projects/conda/en/22.11.x/user-guide/concepts/pkg-specs.html
- 4: PEP 440 prerelease handling conda/conda#11797
- 5: Exclude Pre-Releases conda/conda#5021
Keep the CUDA 12 upper bound at <13.0a0. <13.0 can admit 13.0* prereleases in conda solves, so dropping the a0 broadens the allowed range across the repeated pins in the env files, recipe, and dependencies YAML.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@conda/environments/all_cuda-129_arch-aarch64.yaml` at line 13, The CUDA
version pin is too broad and can allow 13.0 prereleases in conda solves. Update
the CUDA constraint in the relevant repeated pin locations, including the
environment YAML, recipe, and dependencies YAML, to keep the upper bound at
13.0a0 rather than 13.0; use the existing cuda-bindings pin as the reference
point for the exact version spec format.
|
/merge |
2 participants
Description
Contributes to rapidsai/build-planning#285
cuda-pythonis a metapackage and sometimes pulls in components that RAPIDS libraries don't need. This PR is part of a series dropping direct use ofcuda-pythonin favor of depending only on those specific components.cuda-pythoncuda-bindings >=12.9.2,<13.0(CUDA 12),cuda-bindings >=13.0.1,<14.0(CUDA 13)cuda-bindingsin CINotes for Reviewers
Why these specific bounds?
cuda-pythoncuda-bindingsmajor version follows the CTK major version, so kept a ceiling just like we currently have forcuda-python