Skip to content
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

Port all conda recipes to rattler-build #18054

Open
wants to merge 51 commits into
base: branch-25.04
Choose a base branch
from

Conversation

gforsyth
Copy link
Contributor

@gforsyth gforsyth commented Feb 20, 2025

Description

Port all condabuild recipes over to use rattler-build instead.

Contributes to rapidsai/build-planning#47

  • To satisfy rattler, this changes all the licenses in the pyproject.toml files to the SPDX-compliant Apache-2.0 instead of Apache 2.0

Checklist

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.

@gforsyth gforsyth added improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels Feb 20, 2025
@gforsyth gforsyth requested review from a team as code owners February 20, 2025 16:40
@gforsyth gforsyth requested a review from msarahan February 20, 2025 16:40
@github-actions github-actions bot added Python Affects Python cuDF API. cudf.polars Issues specific to cudf.polars pylibcudf Issues specific to the pylibcudf package labels Feb 20, 2025
@gforsyth gforsyth changed the title Add rattler-build recipe for libcudf Port all conda recipes to rattler-build Feb 20, 2025
Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial comments attached. Please also see my review on UCXX and apply any relevant requests from that PR to this one, too.

--channel-priority disabled \
--output-dir "$RAPIDS_CONDA_BLD_OUTPUT_DIR" \
--test skip \
-c "${CPP_CHANNEL}" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We prefer long flags for verbosity wherever possible. Please apply this throughout.

Suggested change
-c "${CPP_CHANNEL}" \
--channel "${CPP_CHANNEL}" \

run:
- python
- pylibcudf =${{ version }}
- polars >=1.20,<1.23
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure this pinning is up to date before merging. These values change frequently.

Copy link
Contributor

@bdice bdice Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is being updated in #18076. Bump it if that merges before this PR.

@gforsyth
Copy link
Contributor Author

Computers are the absolute worst.

Despite RAPIDS_CUDA_VERSION being a string, apparently in the process of splitting and extracting the major version, we're getting an integer instead:

       "context": {
        "version": "25.04.00a223",
        "minor_version": "25.04",
        "cuda_version": "11.8",
        "cuda_major": 11,
        "date_string": 250221,
        "head_rev": "1708a669"
      },

rattler-build has a filter for converting from string to int, but not from int to string.
I also can't reproduce this locally.

@gforsyth
Copy link
Contributor Author

rattler-build has a filter for converting from string to int, but not from int to string.
I also can't reproduce this locally.

Ok, wrapping in quotation marks works. It's very strange that this happens in only some repos, but I'll add "wrap these in strings all the time" to the rattler playbook

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder to revert this before merging.

Comment on lines 76 to 78
- numba-cuda >=0.2.0,<0.3.0a0
- numba >=0.59.1,<0.61.0a0
- numpy >=1.23,<3.0a0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#18078 will bump these. Check that PR's status before merging.

- pylibcudf =${{ version }}
- ${{ pin_compatible("rmm", upper_bound="x.x") }}
- fsspec >=0.6.0
- if: cuda_major == "11"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- if: cuda_major == "11"
- if: cuda_major == "11"

- python:
imports:
- dask_cudf
pip_check: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's circle back to this later. I want to pass pip_check if possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 23 to 29
- cudf_ROOT="$(realpath ./cpp/build)"
- export cudf_ROOT
- >
./build.sh -n -v \
libcudf libcudf_kafka benchmarks tests \
--build_metrics --incl_cache_stats --allgpuarch \
--cmake-args=\"-DCMAKE_INSTALL_LIBDIR=lib -DCUDF_ENABLE_ARROW_S3=ON\"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use a single content: | block as suggested for ucxx.

- cmake ${{ cmake_version }}
- ${{ compiler("c") }}
- ${{ compiler("cxx") }}
- ${{ compiler("cuda") }} =${{ cuda_version }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- ${{ compiler("cuda") }} =${{ cuda_version }}
- ${{ compiler("cuda") }}

Comment on lines 187 to 189
- if: cuda_major != "11"
then:
- cuda-nvtx-dev
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember why we have a -dev package in run: here. 🤔 I think there is a reason but it escapes me. If we have extra cycles later, let's come back to this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a typo (by me) -- the original conda-build recipe just has conda-nvtx in there.

- packaging
ignore_run_exports:
from_package:
- if: not (cuda_major == "11")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like we've had this working elsewhere:

Suggested change
- if: not (cuda_major == "11")
- if: cuda_major != "11"

Copy link

copy-pr-bot bot commented Feb 25, 2025

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@gforsyth
Copy link
Contributor Author

/ok to test

Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have only a few leftover comments. However, I think we should merge this soon and work out the remaining items in a follow-up PR wherever we can. Getting this in will help us see any problems, and it'll help with reducing merge conflicts with other work that is going on.

Comment on lines 24 to 25
content:
- ./build.sh cudf
Copy link
Contributor

@bdice bdice Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to make changes like this across all the recipes?

Suggested change
content:
- ./build.sh cudf
content: ./build.sh cudf

or

Suggested change
content:
- ./build.sh cudf
content: |
./build.sh cudf

./build.sh -n -v \
libcudf libcudf_kafka benchmarks tests \
--build_metrics --incl_cache_stats --allgpuarch \
--cmake-args=\"-DCMAKE_INSTALL_LIBDIR=lib -DCUDF_ENABLE_ARROW_S3=ON\"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if -DCMAKE_INSTALL_LIBDIR=lib is still necessary. I think that maybe we needed that because rapids-cmake wasn't always conda-aware, and we were getting lib64 instead of lib. I'd like to check the package contents and see if they change if this flag is removed (and see if tests pass).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed the libdir arg, we'll see what happens

- package:
name: libcudf-example
version: ${{ version }}
build:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How'd we get away without an env: section here? In rapidsai/rmm#1800 it seemed like I needed one...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blind luck, I wager

@gforsyth
Copy link
Contributor Author

/ok to test

@gforsyth gforsyth force-pushed the rattler-build branch 2 times, most recently from bec4719 to e27c1f3 Compare February 26, 2025 16:36
@vyasr
Copy link
Contributor

vyasr commented Feb 26, 2025

rattler-build has a filter for converting from string to int, but not from int to string.
I also can't reproduce this locally.

Ok, wrapping in quotation marks works. It's very strange that this happens in only some repos, but I'll add "wrap these in strings all the time" to the rattler playbook

Is there a minimal "expected" behavior here that we could capture and write up in a rattler issue?

@gforsyth
Copy link
Contributor Author

Is there a minimal "expected" behavior here that we could capture and write up in a rattler issue?

I think it might be:

Given that shells have horrendously inconsistent behavior around types, make everything a string unless someone explicitly calls | int

@vyasr
Copy link
Contributor

vyasr commented Feb 26, 2025

Is there a minimal "expected" behavior here that we could capture and write up in a rattler issue?

I think it might be:

Given that shells have horrendously inconsistent behavior around types, make everything a string unless someone explicitly calls | int

That seems sensible. Want to write that up as a rattler-build issue?

@gforsyth
Copy link
Contributor Author

That seems sensible. Want to write that up as a rattler-build issue?

will do

@gforsyth
Copy link
Contributor Author

rattler-build issue for context types: prefix-dev/rattler-build#1451

@@ -20,6 +20,15 @@ cache:
build:
script:
content: |

# Remove `-fdebug-prefix-map` line from CFLAGS and CXXFLAGS so the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What adds these flags?

Copy link
Contributor Author

@gforsyth gforsyth Feb 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both conda-build and rattler-build add them in this file in the build environment:
/etc/conda/activate.d/activate-gxx_linux-64.sh

https://github.com/search?q=repo%3Aconda-forge%2Fctng-compiler-activation-feedstock%20fdebug&type=code

There's a line in there like -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION}

but conda-build uses the recipe name and leaves $PKG_VERSION unset, so it doesn't bust the cache.

upstream issue opened to fix this: prefix-dev/rattler-build#1458

but it might take a bit of time to get a fix so adding the workaround here to get us unblocked.

@@ -0,0 +1,127 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/prefix-dev/recipe-format/main/schema.json
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want, then this line can be ommitted as recipe.yaml is in the schema store now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cudf.polars Issues specific to cudf.polars improvement Improvement / enhancement to an existing function non-breaking Non-breaking change pylibcudf Issues specific to the pylibcudf package Python Affects Python cuDF API.
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

4 participants