Use rapids-build-backend.

[bdice]

Description

This PR uses rapids-build-backend to simplify wheel builds and reduce the complexity of various CI/build scripts.

See also:

• https://github.com/rapidsai/rapids-build-backend
• Update RAPIDS Python packages to use the new rapids-build-backend build-planning#31
• Use rapids-build-backend. cudf#15245
• Build C++ wheel #1529

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[jameslamb]

We're not targeting the 24.06 release for this. I'll keep the DO NOT MERGE label on and retarget this at branch-24.08 once that exists.

[jameslamb]

Since I retargeted this at branch-24.08, the two devcontainer builds are failing like this:

  About to run devcontainer build --workspace-folder /home/runner/_work/rmm/rmm --config /home/runner/_work/rmm/rmm/.devcontainer/cuda12.2-conda/devcontainer.json --image-name undefined:latest
  [2024-05-21T14:56:50.141Z] @devcontainers/cli 0.60.0. Node.js v16.20.2. linux 6.5.0-1020-aws x64.
  
  Error: Dev container build failed: Command failed: docker inspect --type image rapidsai/devcontainers:24.08-cpp-mambaforge-ubuntu22.04 (exit code: undefined)
  An error occurred building the container.
  Error: Command failed: docker inspect --type image rapidsai/devcontainers:24.08-cpp-mambaforge-ubuntu22.04

(build link)

That --image-name undefined:latest looks suspicious, but I'd have to dig a bit to find where that's coming from. Saw something similar this morning on a cuml PR targeting branch-24.08: rapidsai/cuml#5901

[vyasr]

The devcontainers probably hadn't been built yet, those builds were manually kicked off just 4 hours ago. I've kicked off a rerun to test.

[jameslamb]

Yep that worked (build link), thanks @vyasr

[vyasr]

Couple of small things, but approving since I don't need to look at this again unless something comes up.

[vyasr]

Just noticed this in the raft PR and it reminded me: do we also need to add a disable-cuda in the build.sh invocations?

[KyleFromNVIDIA]

do we also need to add a disable-cuda in the build.sh invocations?

Yes, but it needs to be rapidsai.disable-cuda once rapidsai/rapids-build-backend#37 is merged.

[jameslamb]

Alright I've updated this with the following changes:

• moved rapids-build-backend floor to 0.3.0
• passed --config-settings rapidsai.disable-cude=true in build.sh
• consolidated rapids-generate-version calls based on Use rapids-build-backend. #1502 (comment)
• changed librmm/_version.py to also use the __package__ pattern (instead of string literal "librmm")
• added __all__ lists to _version.py
  • (noticed @KyleFromNVIDIA doing this in Use rapids-build-backend cuml#5804, I think it's nice to clarify intent and to avoid re-exporting other things from that module)

That's enough changes that I think this should get another review if you have time @vyasr .

[vyasr]

Couple more small notes, but approving assuming that they're addressed.

[jameslamb]

I just pushed one more change... remembered that pip accepts --config-settings (with an s), not --config-setting.

https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-C

Having --config-setting (no s) didn't break anything in CI or even display any warnings, so maybe newer versions of pip have code to capture both. But either way, I think --config-settings (with the s) is the right thing for pip install, given that's what is in that tool's docs.

I'll apply that change to the cudf PR. cc @KyleFromNVIDIA that should be applied to the other rapids-build-backend PRs as well.

[jameslamb]

I just pushed one more tiny change (#1502 (comment)).

I think all the review comments have been addressed, so if CI passes, I'll merge this.

[jameslamb]

/merge