-
Notifications
You must be signed in to change notification settings - Fork 54
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
add wheel output #369
add wheel output #369
Conversation
Yeah for consistency with the rest of RAPIDS using separate C++ and Python wheels is the way to go. We'll be able to leverage that by using the libkvikio wheel during the libcudf wheel build since libcudf needs libkvikio headers. You can see that in your cudf PR those are currently being bundled into the libcudf wheel which is not ideal. Using the libkvikio wheel from this PR instead will fix that. |
Error in wheel build:
|
rapidsai/kvikio#369 moves the python wheel code one level deeper so that we add support for a dedicated libkvikio wheel. This adjustment needs to be accounted for here. Confused PR run without this change: https://github.com/rapidsai/kvikio/actions/runs/8900188332/job/24441209009#step:7:1446
Feel free to add this to the devcontainer build job to test the path adjustment in the devcontainers before merging: build_command: |
sudo yq -i '.repos[2].python[0].sub_dir = "python/kvikio"' /opt/rapids-build-utils/manifest.yaml;
rapids-generate-scripts; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reservations from me. If it’s working as expected, the diff looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I'm still reviewing, but publishing this now so you can start making adjustments to some of the rapids-build-backend
stuff.
Co-authored-by: James Lamb <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for all your work!
(and to @hcho3 for helping move it forward too)
Indeed! Thanks @hcho3 for moving this forward! |
/merge |
Contributes to rapidsai/build-planning#31 Removes `.gitattributes` file. That was added in #88 for use with `versioneer`. Per the `git` docs ([link](https://git-scm.com/docs/gitattributes#_export_subst)), setting the attribute `export-subst` on a file via a `.gitattributes` tell `git` to replace placeholders in the file with some `git` information. This is no longer done in `_version.py` files in this project, and this project no longer uses `versioneer`. `rapids-build-backend` handles storing git commit information in the published packages. ## Notes for Reviewers Created based on this conversation: rapidsai/kvikio#369 (comment) Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Peter Andreas Entschev (https://github.com/pentschev) - Mike Sarahan (https://github.com/msarahan) URL: #1350
* Account for kvikio python folder nesting rapidsai/kvikio#369 moves the python wheel code one level deeper so that we add support for a dedicated libkvikio wheel. This adjustment needs to be accounted for here. Confused PR run without this change: https://github.com/rapidsai/kvikio/actions/runs/8900188332/job/24441209009#step:7:1446 * Update features/src/rapids-build-utils/opt/rapids-build-utils/manifest.yaml * add libkvikio python build; bump feature version * add CMake args back * reorder libkvikio to build before kvikio, bump feature version --------- Co-authored-by: Vyas Ramasubramani <[email protected]> Co-authored-by: Vyas Ramasubramani <[email protected]> Co-authored-by: ptaylor <[email protected]> Co-authored-by: Paul Taylor <[email protected]>
Contributes to rapidsai/build-planning#69. Proposes a stricter pattern for passing a `libkvikio` wheel from the `wheel-build-cpp` job that produced it into the `wheel-build-python` job wanting to use it (as a build dependency of `kvikio`). This change improves the likelihood that issues with the `libkivkio` wheels will be caught in CI. ## Notes for Reviewers See rapidsai/rmm#1586 and rapidsai/build-planning#69 (comment) for details on how I tested this approach. I didn't propose this on #369 because I hadn't quite finished testing the approach yet. But I do think we should do this for all of the C++ wheels (rapidsai/build-planning#33). Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Mike Sarahan (https://github.com/msarahan) URL: #397
closes #250
I'm not sure if it makes sense to split the wheel into one dedicated wheel for the shared library, and another for the python wrapper. That's what @vyasr has been doing on other libraries, like rapidsai/rmm#1529. If it makes sense here, I'll add that.