Conversation
Sorry, something went wrong.
xgboost's Python package is a scikit-build-core project whose CMakeLists builds libxgboost.so from the sibling C++ tree and installs it into xgboost/lib. `wheel.py-api = "py3"` makes that a single py3-none-<plat> wheel, so the port is upstream's macOS cibuildwheel job (ops/pipeline/build-python-wheels-macos.sh) narrowed to manylinux_riscv64, with one deviation: - upstream's committed pyproject.toml is the CUDA variant and requires nvidia-nccl-cu13 on Linux, which does not exist for riscv64. The workflow regenerates it with `ops/script/pypi_variants.py --use-suffix=na --require-nccl-dep=na`, which is the NCCL-free `xgboost` upstream already publishes for macOS and win_arm64. Tests are upstream's `cpu-arm64` suite from ops/pipeline/test-python-wheel.sh, unchanged. scikit-learn is compiled in-container rather than dropped: xgboost.testing importorskips sklearn.datasets at module level, so without it every test module skips wholesale and the run proves nothing. numpy/scipy/pandas come from the registry as wheels via PIP_ONLY_BINARY, scoped to the test phase. The wheel vendors the image's libgomp.so.1 (auditwheel), hence the gpl_sources job. Validated on aarch64 in the same Rocky 10 manylinux image family: the wheel builds in 14m CPU, carries xgboost/lib/libxgboost.so plus xgboost.libs/libgomp-*.so.1.0.0 and dist-info/licenses/LICENSE, and the suite passes 34/34 against a cibuildwheel-shaped staged test cwd. A cmake configure under linux/riscv64 in manylinux_2_39_riscv64 succeeds (gcc 14.3.1, OpenMP 4.5, SSE2 correctly not selected). Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Depends on scikit-learn |
Sorry, something went wrong.
|
Confirmed, but it is a sequencing note rather than a blocker: this run is green today with scikit-learn compiled from sdist in-container (~22 min of the 63 min job), and the port is not waiting on anything. pypi.riseproject.dev/simple/scikit-learn/ still 302s to pypi.org, so #339 has not published yet. When it does, no change is needed here: scikit-learn is deliberately absent from PIP_ONLY_BINARY and CIBW_ENVIRONMENT already carries PIP_EXTRA_INDEX_URL, so pip resolves it from the registry as a wheel and the in-container compile disappears on its own. The versions line up — #339 builds 1.9.0, which is what PyPI resolves to and what this run compiled — so pip will prefer our wheel rather than a newer PyPI sdist. |
Sorry, something went wrong.
scikit-build-core project compiling the sibling C++ tree into libxgboost.so, loaded through ctypes. Upstream publishes py3-none-manylinux wheels for x86_64 and aarch64 only.
Mirrors upstream's python_wheels_manylinux.yml.
Differs from upstream
Matrix: one py3-none wheel — wheel.py-api = "py3", no CPython ABI involved.
Testing
License: ✅ Wheel ships dist-info/licenses/LICENSE (Apache-2.0). auditwheel bundles the image's libgomp, so a gpl_sources job publishes gcc sources against the same pinned image.
34 passed. build_info() reports USE_OPENMP: True, USE_CUDA: False, USE_NCCL: False.