Skip to content

build and test conda packages in CI#99

Merged
rapids-bot[bot] merged 10 commits intorapidsai:mainfrom
jameslamb:add-conda-packages
May 29, 2025
Merged

build and test conda packages in CI#99
rapids-bot[bot] merged 10 commits intorapidsai:mainfrom
jameslamb:add-conda-packages

Conversation

@jameslamb
Copy link
Copy Markdown
Member

Closes #89

  • adds conda CI (for PRs and branch builds)
  • uses rattler-build for builds, matching the direction RAPIDS is moving (Replace conda-build with rattler-build build-planning#47)
  • move version into a root-level VERSION file (so it can be referenced in both pyproject.toml and the rattler-build recipe)
  • bumps version to 0.1.1 (so we'll see packages get published)
  • introduces rapids-dependency-file-generator
    • to start, just to avoid duplicating testing dependencies into test_python.sh
    • and for consistency with other RAPIDS projects
    • if we agree on this, I'll go further in a follow-up PR and use it to automatically manage pyproject.toml

@jameslamb jameslamb added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels May 28, 2025
Comment thread .pre-commit-config.yaml
rev: v0.10.0.1
hooks:
- id: shellcheck
args: ["--severity=warning"]
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This suppresses warnings like this that come from source-ing scripts from https://github.com/rapidsai/gha-tools in CI scripts:

In ci/build_python.sh line 6:
source rapids-date-string
       ^----------------^ SC1091 (info): Not following: rapids-date-string was not specified as input (see shellcheck -x).


In ci/build_python.sh line 14:
source rapids-rattler-channel-string
       ^---------------------------^ SC1091 (info): Not following: rapids-rattler-channel-string was not specified as input (see shellcheck -x).


In ci/test_python.sh line 6:
. /opt/conda/etc/profile.d/conda.sh
  ^-- SC1091 (info): Not following: /opt/conda/etc/profile.d/conda.sh was not specified as input (see shellcheck -x).

I think saying "don't treat info-level findings as errors" is preferable to individually skipping those points with # shellcheck disable comments, just for readability and reduced development friction.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Not sure if apply but maybe a comment in the yaml might help for future reference.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Sure!

Did that here: f224cf3

Comment thread VERSION
@@ -0,0 +1 @@
0.1.1
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

As of this PR, proposing we just use a version in a file.

Updating this file will be required to do a new release. In the near future, it'd probably be better to read this version from git tags, as most other RAPIDS projects do.

Comment thread pyproject.toml
[build-system]
requires = [
"setuptools>=64.0.0",
"setuptools>=77.0.0",
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Comment thread dependencies.yaml
@@ -0,0 +1,46 @@
# Dependency list for https://github.com/rapidsai/dependency-file-generator
files:
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

For this PR, adding just enough in dependencies.yaml to set up the environment for conda-based tests in CI.

If we agree on using rapids-dependency-file-generator here, I'll do a follow-up PR using this for pyproject.toml too.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there any advantage to use rapids-dependency-file-generator at this stage of the project? why should we?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes I think so. I think that will become clearer in the follow-up PR I'll add that also manages pyproject.toml dependencies... less stuff to keep in sync across multiple places.

@jameslamb jameslamb changed the title WIP: build and test conda packages in CI build and test conda packages in CI May 28, 2025
@jameslamb jameslamb marked this pull request as ready for review May 28, 2025 18:18
@jameslamb jameslamb requested a review from a team May 28, 2025 18:19
Copy link
Copy Markdown
Contributor

@ncclementi ncclementi left a comment

Choose a reason for hiding this comment

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

Just left couple of comments and question mostly for understanding, but no blockers.

Comment thread .github/workflows/build.yaml Outdated
Comment thread .github/workflows/pr.yaml
- name: Run pre-commit
uses: pre-commit/action@v3.0.1
build-wheel:
conda-python-build:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we want to build the package on every PR? or are we doing this juts to test?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes I think we should build it on every PR. We do that across much of RAPIDS.

Building is cheap, and doing it often spreads the development work like "some upstream dependency broke and our stuff is broken" more evenly over time than, say, only building at release time.

If we wanted to avoid that in the future, we could use something like the changed-files workflow to implement behavior like "only run certain types of CI workflows based on which files were changed".

Example of that: https://github.com/rapidsai/cuml/blob/9f829c3e87fd3ee59297dfafd60a475620635342/.github/workflows/pr.yaml#L61-L78

Comment thread .pre-commit-config.yaml
rev: v0.10.0.1
hooks:
- id: shellcheck
args: ["--severity=warning"]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Not sure if apply but maybe a comment in the yaml might help for future reference.

Comment thread dependencies.yaml
@@ -0,0 +1,46 @@
# Dependency list for https://github.com/rapidsai/dependency-file-generator
files:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there any advantage to use rapids-dependency-file-generator at this stage of the project? why should we?

@jameslamb
Copy link
Copy Markdown
Member Author

/merge

@rapids-bot rapids-bot Bot merged commit 4a846b9 into rapidsai:main May 29, 2025
22 checks passed
@jameslamb jameslamb deleted the add-conda-packages branch May 29, 2025 14:33
rapids-bot Bot pushed a commit that referenced this pull request May 29, 2025
Follow-up to #99 

Fixes the failing conda builds:

> The workflow is not valid. .github/workflows/build.yaml (Line: 18, Col: 13): Job 'conda-python-build' depends on unknown job 'checks'. .github/workflows/build.yaml (Line: 25, Col: 13): Job 'upload-conda' depends on job 'conda-python-build' which creates a cycle in the dependency graph.

([build link](https://github.com/rapidsai/rapids-cli/actions/runs/15326288414))

Adds more use of `rapids-dependency-file-generator` for managing dependencies.

Also bumps the version to 0.1.2, to pick up the slight change to wheel metadata (`importlib-metadata`, not `importlib_metadata`: https://pypi.org/project/importlib-metadata/)

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Naty Clementi (https://github.com/ncclementi)

URL: #101
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add conda packages

2 participants