-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treat clobber warnings as errors for conda builds #54
Comments
Adding an example for reference on how to investigate the contents of these files. # choose a conda package from https://anaconda.org/rapidsai/librmm/files
RMM_CONDA_PACKAGE=https://anaconda.org/rapidsai/librmm/24.04.00/download/linux-64/librmm-24.04.00-cuda12_240410_g8f19c9c3_0.tar.bz2
# download it
wget \
"${RMM_CONDA_PACKAGE}" \
-O librmm.tar.bz2
# list its contents, filtering down for paths mentioned in the clobber errors
tar jtf ./librmm.tar.bz2 \
| grep -E 'fmt|spdlog' For a recent version of fmt and spdlog headers and static libraries (click me)
|
Open PRs:
|
Short SummaryIt looks to me like the root cause of the
And I think there are 2 classes of fixes we could pursue.
DetailsI'm able to reproduce the errors about clobbering docker run \
--rm \
-v $(pwd):/opt/rmm \
-w /opt/rmm \
-it rapidsai/ci-conda:cuda12.2.2-ubuntu22.04-py3.9-amd64 \
bash
# do a 'librmm' conda build
ci/build_cpp.sh I removed the (link to diff on my rapids-cmake fork) We could immediately resolve these
But separately, we should try to permanently fix this so the clobbering issues don't re-appear in similar situations in the future. If we want to preserve the ability to substitute in sources with not-yet-upstreamed patches in our conda builds, I can think of 2 options:
Downloading to a project-specific path would be fine for headers and source files, but I'm not sure how to handle other types of files that we're getting clobbering warnings for like:
Note I'm saying "project-specific" here because every RAPIDS package using For example, look at the conda builds on rapidsai/cuml#5821. It's getting 3 packages all trying to install the same
So if NotesThere are other clobber warnings, just starting with |
Linking these related things (thanks @vyasr for the pointer). There is already a |
We don't publish |
Ah ok. I missed the "as CI artifacts" part of the description in rapidsai/rapids-cmake#414. Thank you, edited my original post. |
I just put up a PR to build the latest version of That'll be helpful whenever we decide to upgrade and drop the patch in |
I've looked across all the open PRs that add this setting: conda config --set path_conflict prevent And see the following common issues. 1:
|
Contributes to rapidsai/build-planning#54 Ensures that conda builds will fail in the presence of multiple packages with identical paths Authors: - Jake Awe (https://github.com/AyodeAwe) - James Lamb (https://github.com/jameslamb) Approvers: - Ajay Thorve (https://github.com/AjayThorve) - Ray Douglass (https://github.com/raydouglass) URL: #583
Contributes to rapidsai/build-planning#54. The `libraft-headers` and `libraft-headers-only` conda packages are bundling `rmm`'s headers. I believe that's because the `librmm` conda package isn't available in the `libraft*` conda build environment, and as a result it's getting `rmm` via CPM (thanks to `rapids-cmake`). As a result, this project and any that depend on it are seeing warnings like the following in conda builds where `conda`'s `path_conflict` setting is set to `warn` or `prevent` (like #2245): ```text This transaction has incompatible packages due to a shared path. packages: rapidsai-nightly/linux-64::librmm-24.04.00a38-cuda11_240326_ga98931b9_38, rapidsai-nightly/linux-64::libraft-headers-only-24.04.00a93-cuda11_240326_g9637b3c2_93 path: 'include/rmm/mr/device/arena_memory_resource.hpp' ``` To fix that, this proposes the following changes: * make `librmm` a `host` dependency of the following conda packages: `libraft-headers-only`, `libraft-headers` ### Benefits of this change * slightly smaller `libraft-headers` and `libraft-headers-only` conda packages * reduced risk of runtime and installation issues caused by file clobbering ## Notes for reviewers ### History of changes to the `librmm` dependency for `libraft-headers`: * both `run` and `host`: #508 * both `run` and `host`, but ignoring its `run_exports`: #1264 * just `run`, but ignoring its `run_exports`: #2102 In particular, #2102 referred to the `host` dependency on `librmm` as "extraneous" but from a packaging perspective, I don't think it is. `librmm` being in `host` means it'll be present in the build environment, which means its headers will be *found* instead of *downloaded*, and therefore not packaging into the `libraft*` conda packages. ### How I tested this Built all the `raft` conda packages locally from `branch-24.06` and confirmed that they contain `rmm` headers. Then again from this branch and confirmed they were gone. ```shell docker run \ --rm \ --env-file "${PWD}/aws-creds.env" \ -v $(pwd):/opt/work \ -w /opt/work \ -it rapidsai/ci-conda:cuda12.2.2-ubuntu22.04-py3.10-amd64 \ bash CI="true" \ ci/build_cpp.sh # On 'branch-24.06', this showed the rmm headers being packaged. # On this branch, they're omitted. tar --bzip2 -tf \ /tmp/conda-bld-output/linux-64/libraft-headers-only-24.06.00a50-cuda12_240430_g1e0e2283_50.tar.bz2 \ | grep 'include/rmm' \ | wc -l ``` Also checked the CI logs from `conda-cpp-build` jobs here. On other recent PRs, I see CPM downloading `rmm` ... ```text -- CPM: Adding package [email protected] (branch-24.06) ``` ... and all the `rmm` headers getting installed as part of the `libraft-headers` package ```text -- Installing: /opt/conda/conda-bld/_h_env_placehold_placehold_..._placeho/include/rmm/cuda_stream.hpp ``` ([build link](https://github.com/rapidsai/raft/actions/runs/8904352932)) Here, I see `librmm` coming through via the conda package requirements ... ```text The following NEW packages will be INSTALLED: ... librmm: 24.06.00a17-cuda12_240430_g26fa9ecb_17 rapidsai-nightly ``` ... and being used instead of downloads via CPM ... ```text -- CPM: Using local package [email protected] ``` ... and no installation of the `rmm` headers as part of building any `libraft` packages. ([build link](https://github.com/rapidsai/raft/actions/runs/8910675575/job/24470450187?pr=2284)) Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Bradley Dice (https://github.com/bdice) - Ray Douglass (https://github.com/raydouglass) URL: #2284
I'm pausing on this for now to help out with some of the other initiatives (like #31 and #33). I believe rapidsai/raft#2284 fixed the issues with |
Thanks for the update James! I agree that those two are more immediate priorities, but the progress you've already made on here is great. |
## Description Replaces #15603 Contributes to: * rapidsai/build-planning#54 * rapidsai/build-planning#56 * rapidsai/rapids-cmake#387 Now that most of `conda-forge` has been updated to `fmt >=11.0.1,<12` and `spdlog>=1.14.1,<1.15` (rapidsai/build-planning#56 (comment)), we're attempting to upgrade RAPIDS to similar versions of those libraries. This improves the likelihood that RAPIDS will be installable alongside newer versions of its dependencies and complementary packages on conda-forge. ## Notes for Reviewers This PR is testing changes made in rapidsai/rapids-cmake#689. It shouldn't be merged until those `rapids-cmake` changes are merged and any testing-specific details have been removed.
Created a subissue for this task: #109 |
(Apr 23, 2024) moved from an internal tracking board. The description here is @ajschmidt8 's original write-up of the issue.
Problem
Some of our conda builds suffer from
ClobberWarning
s (e.g. here and here).Ignoring these clobber warnings can sometimes result in packaging issues. Therefore, we'd like to begin treating these clobber warnings as errors.
Ideally, this setting should go in the
.condarc
file of our CI images (i.e. here) so that it applies to every RAPIDS repository.However, since many repositories already suffer from clobber warnings, this would break CI for a lot of people.
Therefore, we need to plan the rollout carefully.
Solution
To roll out this new configuration setting safely, we should do the following:
For each of the repositories in the section below:
a. Open a PR and add the following line to any build scripts (e.g.
ci/build_{cpp,python}.sh
):conda config --set path_conflict prevent
b. Resolve any build issues that result from this change
c. If build issues occur, fix them and merge the PR (leaving in the new conda config line, that will be cleaned up later)
d. If no build issues occur, simply close the PR
e. Link the PR in this issue (do not link this issue in the PR, since this issue is in a private repository)
Once all of the repositories are successfully using the new conda config setting, add the setting to https://github.com/rapidsai/ci-imgs/blob/main/context/condarc.tmpl
Go back and clean up all of the extraneous
conda config --set path_conflict prevent
lines in each repositoryRepositories
Look at the repos at this search query.
The text was updated successfully, but these errors were encountered: