Skip to content

WIP: wheels CI: write constraints directly to PIP_CONSTRAINT#62

Closed
jameslamb wants to merge 1 commit intorapidsai:mainfrom
jameslamb:pip-constraints
Closed

WIP: wheels CI: write constraints directly to PIP_CONSTRAINT#62
jameslamb wants to merge 1 commit intorapidsai:mainfrom
jameslamb:pip-constraints

Conversation

@jameslamb
Copy link
Member

Description

Contributes to rapidsai/build-planning#256 / rapidsai/build-planning#257

rapidsai/gha-tools#247 updates rapids-generate-pip-constraints in the following ways:

  • generates output for RAPIDS_DEPENDENCIES="latest" (previously silently generated an empty list of constraints)
  • appends to the passed-in file if it already exists
  • always passes use_cuda_wheels=true

That new behavior will help with testing wheels against different CTK versions via constraints on the cuda-toolkit metapackage.

@jameslamb jameslamb added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels Mar 4, 2026
@copy-pr-bot
Copy link

copy-pr-bot bot commented Mar 4, 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.

@jameslamb
Copy link
Member Author

/ok to test

@github-actions github-actions bot added the ci label Mar 4, 2026
rapids-bot bot pushed a commit to rapidsai/gha-tools that referenced this pull request Mar 5, 2026
Contributes to rapidsai/build-planning#256

`rapids-generate-pip-constraints` currently special-cases `RAPIDS_DEPENDENCIES="latest"` and skips generating constraints in that case.

This will be helpful in rapidsai/build-planning#256, where we want to start constraining `cuda-toolkit` in wheels CI based on the CTK version in the CI image being used.

## Notes for Reviewers

### How I tested this

Looked for projects using this ([GitHub search](https://github.com/search?q=org%3Arapidsai+language%3AShell+%22rapids-generate-pip-constraints%22+AND+NOT+is%3Aarchived+&type=code)) and tested in them.

It's just a few:

* [ ] cudf (rapidsai/cudf#21639)
* [ ] cuml (rapidsai/cuml#7853)
* [ ] dask-cuda (rapidsai/dask-cuda#1632)
* [ ] nvforest (rapidsai/nvforest#62)
* [ ] raft (rapidsai/raft#2971)
* [ ] rmm (rapidsai/rmm#2270)

On all of those, wheels CI jobs worked exactly as expected and without needing any code changes or `dependencies.yaml` updates... so this PR is safe to merge any time.

### Is this safe?

It should be (see "How I tested this").

This is only used to add **constraints** (not requirements), so it shouldn't change our ability to catch problems like "forgot to declare a dependency" in CI.

It WILL increase the risk of `[test]` extras being underspecified. For example, if `cuml[test]` has `scikit-learn>=1.3` and the constraints have `scikit-learn>=1.5`, we might never end up testing `scikit-learn>=1.3,<1.5` (unless it's explicitly accounted for in a `dependencies: "oldest"` block).

The other risk here is that this creates friction because constraints passed to `--constraint` cannot contain extras. So e.g. if you want to depend on `xgboost[dask]`, that cannot be in any of the lists generated by `rapids-generate-pipe-constraints`. I think we can work around that though when we hit those cases.

Overall, I think these are acceptable tradeoffs.

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Bradley Dice (https://github.com/bdice)

URL: #247
@jameslamb
Copy link
Member Author

Closing this.

This was for testing rapidsai/gha-tools#247, which has now been merged.

The changes here will make it into the repo via a PR for rapidsai/build-planning#256

@jameslamb jameslamb closed this Mar 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant