document changes in library-loading, update build-UCX-from-source docs

[jameslamb]

Contributes to rapidsai/build-planning#118

Caused by rapidsai/ucx-wheels#13

I originally came here to document the implications of rapidsai/ucx-wheels#13 in the docs, namely:

• if you have a libucx-cu{11,12} wheel installed, then by default ucx-py will use UCX libraries from that wheel
• environment variable RAPIDS_LIBUCX_PREFER_SYTEM_LIBRARY=true can be set to opt out of this and use a system installation instead

While doing that, I noticed some other opportunities for improvement in the installation docs:

• updating build-UCX-from-source instructions to UCX 1.15 (the oldest version this project now supports)
• clarifying and simplifying some language

Notes for Reviewers

How I tested this

Followed these instructions in a Docker container running on an x86_64 machine with 8 V100s.

docker run \
    --rm \
    --gpus 0 \
    -v $(pwd):/opt/work \
    -w /opt/work \
    -it rapidsai/ci-conda:latest \
    bash

Used conda to set up the build environment:

conda create -n ucx -c conda-forge \
    automake make libtool pkg-config \
    "python=3.12" "setuptools>=64.0" "cython>=3.0.0" \
    cuda-nvcc \
    cuda-cudart-dev \
    cuda-nvml-dev \
    cuda-nvtx-dev \
    cuda-version=12.5

Ran variations of this code snippet to test my install:

python -c "import ucp; print(ucp.get_ucx_version())"

[pentschev]

Thanks @jameslamb I've left a few comments, overall looks good.

[pentschev]

I think this is not the most user-friendly way to phrase this here, unfortunately we do not have UCX-Py explicitly documented in https://docs.rapids.ai/install/ which has a different versioning scheme than the rest of RAPIDS, and thus it would be difficult for someone to understand what Python version is supported for UCX-Py based solely on the RAPIDS version. I agree the way it was documented isn't optimal and I can't think of a better way to do this differently than what it was either.

[jameslamb]

Sure, that makes sense. My main motivation here was to avoid a hard-coded list of versions, since duplicating that kind of information in multiple places makes it more likely that it'll become out of date.

That said.... we do have a rapids-reviser template set up to replace this line when we roll out add-a-new-Python-version updates to all of RAPIDS.

I'll revert this change based on your comments here.

[pentschev]

I agree that would be ideal, unfortunately I think it's not helpful for the users given the different branching.

How does the rapids-reviser work? Can we easily make it replace arbitrary code/docs lines?

[jameslamb]

Alright, no prob! I've reverted that change here.

Can we easily make it replace arbitrary code/docs lines?

Yes totally! You give it a shell script and say "run this on these repos". This type of case is easy to automatically update there with sed, not a problem.

[pentschev]

LGTM, thanks @jameslamb .

[jameslamb]

Thanks @pentschev for continuing to work with me and @vyasr on these patterns for how these libraries find UCX 😁

[jameslamb]

/merge