wheel builds: react to changes in pip's handling of build constraints

[mmccarty]

Description

Contributes to rapidsai/build-planning#242

Modifying ci/build_wheel.sh to

• pass--build-constraint="${PIP_CONSTRAINT}" unconditionally
• unset PIP_CONSTRAINT (set by rapids-init-pip)... it doesn't affect builds as of pip 25.3, and results in an error from pip wheel when set and --build-constraint is also passed

[greptile-apps]

Greptile Summary

This PR adapts the wheel build scripts to work with pip 25.3+, which changed how build constraints are handled. The main change refactors ci/build_wheel.sh to explicitly pass --build-constraint with the constraint file path, then unsets the PIP_CONSTRAINT environment variable to prevent conflicts (pip 25.3+ errors when both the env var and flag are present). The comment in ci/build_wheel_pylibwholegraph.sh was updated to clarify that PIP_CONSTRAINT only affects regular pip commands, not pip wheel builds.

Key changes:

• Refactored pip wheel command to use args array with --build-constraint flag
• Unset PIP_CONSTRAINT after capturing its value to avoid pip 25.3+ conflicts
• Updated copyright headers to 2026
• Clarified documentation about PIP_CONSTRAINT scope

Confidence Score: 4/5

• This PR is safe to merge with minimal risk
• The changes correctly handle pip 25.3+ compatibility by capturing PIP_CONSTRAINT in an array before unsetting it. The bash array captures the value before unsetting, so the constraint file path is preserved. The script's set -euo pipefail provides error handling if PIP_CONSTRAINT is unset when called. One minor concern is that the script now has an implicit dependency on being called from wrapper scripts that set PIP_CONSTRAINT - direct invocation would fail.
• No files require special attention - both changes are straightforward compatibility updates

Important Files Changed

Filename	Overview
ci/build_wheel.sh	Refactored pip wheel command to use --build-constraint and unset PIP_CONSTRAINT for pip 25.3+ compatibility; updated copyright year
ci/build_wheel_pylibwholegraph.sh	Updated comment to clarify PIP_CONSTRAINT behavior; updated copyright year

Sequence Diagram

sequenceDiagram
    participant Wrapper as build_wheel_*.sh
    participant RapidsInit as rapids-init-pip
    participant BuildScript as build_wheel.sh
    participant Pip as pip wheel

    Wrapper->>RapidsInit: source rapids-init-pip
    RapidsInit->>RapidsInit: Set PIP_CONSTRAINT env var
    Wrapper->>BuildScript: Call ./ci/build_wheel.sh
    BuildScript->>BuildScript: Capture PIP_CONSTRAINT in RAPIDS_PIP_WHEEL_ARGS
    BuildScript->>BuildScript: unset PIP_CONSTRAINT
    Note over BuildScript: Prevents conflict in pip 25.3+
    BuildScript->>Pip: rapids-pip-retry wheel --build-constraint="${PIP_CONSTRAINT}"
    Pip->>Pip: Build wheel with constraints
    Pip-->>BuildScript: Return built wheel
    BuildScript->>BuildScript: Run auditwheel repair (if needed)

Loading

[greptile-apps]

Greptile found no issues!

From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

[jameslamb]

Similar to rapidsai/cugraph#5399 (review)... we should also update comments like this, which are now inaccurate

cugraph-gnn/ci/build_wheel_pylibwholegraph.sh

Line 16 in 2910605

# Using env variable PIP_CONSTRAINT (initialized by 'rapids-init-pip') is necessary to ensure the constraints

Using the same language that was checked into RMM: https://github.com/rapidsai/rmm/pull/2212/files#diff-616eb8e64286a9a59a2cd9c77d817fba66ce78ecfdde635db9f4028b74349585R25

I see comments like those in a couple scripts here.

[mmccarty]

Ah, yes. Thanks!

[jameslamb]

This looks ok to me only because it looks like none all of the wheel builds here are using build isolation. I think libwholegraph really should NOT be... I'll file a follow-up PR that does that.

[jameslamb]

/merge