Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Use CUDA math wheels #2415
Use CUDA math wheels #2415
Changes from 13 commits
9ccf865
92ee07c
d6b3714
5bcd36f
f2d4e98
e2073ff
d4e050f
4adbc97
6d772a7
d20ae1a
896a394
1e1fe91
c68119a
7f663a0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
When we first talked about this idea, I was thinking
usa_cuda_wheels
should default tofalse
, so that DLFW / pip devcontainers don't even have to think about it.And then build scripts here in RAPIDS repos that prepare wheels for distribution would opt in to it by passing
use_cuda_wheels=true
through config settings.As I type that, I've come around to the idea that that's not the right balance... one change in DLFW + one change in pip devcontainers is preferable to spreading this complexity around every
build_wheel*.sh
across RAPIDS.So I'm good with this, but once we merge a PR with this pattern, please do go put up the corresponding changes in RAPIDS DLFW and
devcontainers
(devcontainers example: rapidsai/devcontainers#365).Unused matrix selectors are harmless (I think), so
use_cuda_wheels=false
could be added unconditionally in those builds even if not all repos have matrices using that.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.
Will do
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, I added a tasklist with this in it to rapidsai/build-planning#35
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.
One thing I'd like to point out is that devcontainers generates a
requirements.txt
file, while this dependency set only haspyproject.toml
output, so it won't actually get the wheels anyway. Still, I'll submit a PR just in case that ever changes.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.
rapidsai/devcontainers#382
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 think your conclusion that the
devcontainers
PR isn't strictly necessary and is just defensive is correct. Everything below is for the benefit of others reading along or finding this from search, and doesn't change this PR.The claim that this having only
output_type: pyproject
means we don't need to care about it forpip
devcontainers isn't true by itself.The runtime dependencies in the wheel metadata don't strictly have to be correct because in
pip
devcontainers, the package will be built withpip install --no-deps --no-build-isolation
.(devcontainers code link)
That
--no-deps
does mean that the runtime dependencies listed in the wheel's metadata don't have to be correct.So it's
output_type: pyproject
and the fact that these CUDA wheels are only runtime dependencies that together make this change not disruptive for RAPIDS devcontainers.HOWEVER... if the project metadata lists any build dependencies that don't already exist in the environment where that
pip install
runs, that build will fail.So any list in
dependencies.yaml
which had onlyoutput_type: pyproject
which was used to populate wheel build requirements could affectpip
devcontainers, because those requirements would need to all be met by the pre-created build environment.