Replace rapids-xgboost with xgboost in the CI.

[trivialfis]

The CI will continue to install XGBoost from the rapidsai channel until the package is removed. See #185 (comment)

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Updated supported environments to use XGBoost 3.3.0 or newer.
  • Applied the update across CUDA 12.9 and CUDA 13.3 configurations on x86_64 and AArch64 platforms.
  • Standardized testing environments on the current XGBoost package.
  • Updated release automation and licensing notices to reflect the revised configuration.

Walkthrough

The change replaces rapids-xgboost with xgboost>=3.3.0 in CUDA environment and test dependency declarations. The release version update script no longer updates rapids-xgboost and includes an expanded SPDX attribution.

Changes

XGBoost dependency transition

Layer / File(s)	Summary
Update environment and test dependencies conda/environments/all_cuda-129_arch-*.yaml, conda/environments/all_cuda-133_arch-*.yaml, dependencies.yaml	The CUDA environment files and test_python_xgboost dependency now use xgboost>=3.3.0.
Update release version handling ci/release/update-version.sh	The release version update list no longer includes rapids-xgboost. The SPDX attribution now includes affiliates.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• rapidsai/nvforest#170: Modifies the same environment files and dependency entries involving rapids-xgboost.
• rapidsai/nvforest#177: Modifies dependencies.yaml and the XGBoost test dependency.

Suggested reviewers: jameslamb

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided, so its relevance to the changeset cannot be assessed.	Add a brief description that explains the dependency replacement and the affected CI and Conda environment files.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: replacing rapids-xgboost with xgboost in CI dependencies.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[bdice]

Must we specify conda-forge::? I'd like to remove that if it's not strictly necessary.

[trivialfis]

The Rapids channel also has a package named xgboost: https://anaconda.org/channels/rapidsai/packages/xgboost/overview

[trivialfis]

I removed the conda-forge:: prefix to let the CI install xgboost from the rapidsai-nightly channel. It will pick the one from conda forge once we remove the xgboost package from rapids.

Currently, the CI uses strict channel priority and fails to solve conda-forge::xgboost given the xgboost package from the rapidsai nightly, which precedes conda-forge. During this transitional period, we will need to allow the CI to continue installing xgboost from rapids.

[betatim]

So are rapidsainightly::xgboost and conda-forge::xgboostexactly the same package? Why is there the rapidsai nightly package?

I'd like to avoid the case that the package that is installed in the CI changes through a "spooky action at a distance", for example because someone deletes the rapidsainightly package. I'd prefer the change to be something that is the result of taking action in the repo (e.g. merging a PR).

[trivialfis]

The xgboost package from the rapidsai channel has RMM integration, but the conda forge package doesn't. We are deprecating the RMM integration in XGBoost and moving toward the CUDA built-in async memory pool. As a result, the xgboost package in the rapisdai channel is destined for removal.

However, the nvforest CI has strict channel ordering, and the rapids channel comes before the conda-forge channel, which can cause package resolution failures when using the prefix conda-forge::xgboost. To avoid the failure, one could:

• Just let the CI pick the package from rapidsai channel until the "spooky action at a distance". This is the currently chosen approach.
• Wait for the removal from the rapidsai channel, then the CI here will fail, and we merge this PR to fix the CI.
• Re-order the channels or relax the strict channel ordering. I think we can agree this is not preferable.

[betatim]

The reason I don't love the spooky action at a distance approach is that it means that suddenly CI might start failing when the switch happens. A PR that touches nothing related to xgboost might pass for commit N-1 but fail for commit N. It would be great to avoid this and explicitly switch over in a PR where we can see that the switch doesn't break anything or can address the breakage.

However, thinking about the options I can't think of a way to do achieve this goal.

[chyunsu3]

/merge