-
Notifications
You must be signed in to change notification settings - Fork 154
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
wheels: dynamically load libcudf.so
from libcudf
wheel
#1447
Conversation
libcudf.so
from libcudf
wheellibcudf.so
from libcudf
wheel
@@ -134,6 +136,8 @@ requires = [ | |||
"cmake>=3.26.4,!=3.30.0", | |||
"cudf==24.10.*,>=0.0.0a0", | |||
"cython>=3.0.0", | |||
"libcudf==24.10.*,>=0.0.0a0", |
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.
Putting this somewhere on the diff so it can be threaded.
Just realized I may have missed one detail that wouldn't be caught in CI.
@vyasr do we want something like https://github.com/rapidsai/cudf/blob/925530afe8178b7e788ea1a8d4df4c0eb4d042dc/python/cudf/cudf/__init__.py#L3-L11 near the top of cuspatial
's top-level __init__.py
?
I think the answer is yes, so that other libcudf.so
lying around in the environment aren't loaded first by some other import.
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.
Reading the linked code (and where it lives), it seems just doing import cudf
would be sufficient
Though please let me know if I'm missing something
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.
John is right that the import should be sufficient for now. When you create the libcuspatial wheel in the follow-up, though, you'll end up needing to load libcudf there. You can see how I did that in the cugraph PR for raft/cugraph-ops.
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.
Thanks, added an import cudf
in fe7df5d and will adjust when I add libcuspatial
.
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.
All seems fine to me. Please double-check ci/release/update-version.sh
. It may need libcudf and librmm listings.
cuspatial/ci/release/update-version.sh Lines 50 to 53 in e323178
Yep I don't think any changes are needed there. It already had them because the conda recipes reference those packages. |
|
||
# Install additional dependencies | ||
# install build dependencies for fiona | ||
apt update | ||
DEBIAN_FRONTEND=noninteractive apt install -y --no-install-recommends libgdal-dev |
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.
Fiona appears to ship binary wheels
Wonder if this is only needed for some specific case (didn't see Linux ARM packages for example)
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.
Is the question why we install fiona with --no-binary
? If so, I do think arm is one of the reasons, but it may not be the only one. @trxcllnt might remember more.
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.
I don't know the original reason, not having ARM packages seems like a likely candidate.
This PR doesn't change anything about it (it's just showing up in the diff because I'm moving other install-related code around), so I'm going to treat this discussion as non-blocking.
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.
Couple of notes, but I don't need to review again.
@@ -5,6 +5,7 @@ set -euo pipefail | |||
|
|||
package_name=$1 | |||
package_dir=$2 | |||
package_type=$3 |
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.
I guess this is in anticipation of the C++ wheel? I have a very minor preference for sticking that change in the subsequent PR to make the reason more obvious, but now that it's done let's leave it here.
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.
Technically yes, but I think it'd be desirable even if we weren't adding a C++ wheel in this repo.
In my mind, rapidsai/shared-workflows#209 and rapidsai/gha-tools#105 shipped with package-type
defaulting to python
just to avoid having to do updates across all the repos to make progress there.
But that it'd be better to be explicit everywhere (like @bdice mentioned in rapidsai/cudf#15483 (comment)), to avoid issues like rapidsai/cudf#16650.
Anyway yeah, we are adding C++ wheels here very soon so I'll leave this change in here.
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.
Just to clarify: I wasn't meaning the passing of python
to the GHA tool, just the passing of an argument to our script, i.e. we could have hardcoded python
in this script and added the package_type
parameter in a follow-up.
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.
ohhhh ok yeah got it, fair
|
||
# Install additional dependencies | ||
# install build dependencies for fiona | ||
apt update | ||
DEBIAN_FRONTEND=noninteractive apt install -y --no-install-recommends libgdal-dev |
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.
Is the question why we install fiona with --no-binary
? If so, I do think arm is one of the reasons, but it may not be the only one. @trxcllnt might remember more.
python/cuspatial/CMakeLists.txt
Outdated
install_aliased_imported_targets( | ||
TARGETS cuspatial arrow_shared nvcomp::nvcomp nvcomp::nvcomp_gdeflate nvcomp::nvcomp_bitcomp | ||
TARGETS cuspatial |
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.
Actually, now that we've removed all of these targets we should just remove the WheelHelpers altogether and just do a normal CMake install
.
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.
Great point! Done in fe7df5d
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.
Based on the above discussions about importing cudf, Python changes LGTM
/merge |
Description
Contributes to rapidsai/build-planning#33.
Proposes the following for
cuspatial
wheels:libcudf
wheelslibcudf.so
,libnvcomp.so
,libnvcomp_bitcomp.so
, andlibnvcomp_gdeflate.so
libcudf.so
dynamically at runtime instead)And other related changes for development/CI:
pip install
calls into 1 in wheel-testing scriptsdependencies.yaml
changes:depends_on_librmm
anddepends_on_libcudf
groupsgha-tools
wheel uploading/downloading scriptsNotes for Reviewers
Benefits of these changes
Unblocks CI in this repo (ref: #1444 (comment), #1441 (comment)).
Reduces wheel sizes for
cuspatial
wheels by about 125MB 😁cuspatial
cuproj
NOTES: size = compressed, "before" = 2024-08-21 nightlies (c60bd4d), CUDA = 12, Python = 3.11
how I calculated those (click me)
Reduces the amount of additional work required to start shipping
libcuspatial
wheels.Background
This is part of ongoing work towards packaging
libcuspatial
as a wheel.relevant prior work:
libcudf
wheels: adding wheel build for libcudf cudf#15483pip install
calls in CI scripts forcudf
: standardize and consolidate wheel installations in testing scripts cudf#16575cudf
dropping its Arrow library dependency: Remove arrow dependency cudf#16640How I tested this
Confirmed in local builds and CI logs that
cudf
is being found, not built, incuspatial
builds.(build link)
Built
cuspatial
wheels locally and ran all the unit tests, without issue.Checklist