build and test conda packages in CI#99
build and test conda packages in CI#99rapids-bot[bot] merged 10 commits intorapidsai:mainfrom jameslamb:add-conda-packages
Conversation
| rev: v0.10.0.1 | ||
| hooks: | ||
| - id: shellcheck | ||
| args: ["--severity=warning"] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Not sure if apply but maybe a comment in the yaml might help for future reference.
| @@ -0,0 +1 @@ | |||
| 0.1.1 | |||
There was a problem hiding this comment.
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.
| [build-system] | ||
| requires = [ | ||
| "setuptools>=64.0.0", | ||
| "setuptools>=77.0.0", |
There was a problem hiding this comment.
To get the new behavior for project.license-files from setuptools.
| @@ -0,0 +1,46 @@ | |||
| # Dependency list for https://github.com/rapidsai/dependency-file-generator | |||
| files: | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Is there any advantage to use rapids-dependency-file-generator at this stage of the project? why should we?
There was a problem hiding this comment.
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.
ncclementi
left a comment
There was a problem hiding this comment.
Just left couple of comments and question mostly for understanding, but no blockers.
| - name: Run pre-commit | ||
| uses: pre-commit/action@v3.0.1 | ||
| build-wheel: | ||
| conda-python-build: |
There was a problem hiding this comment.
Do we want to build the package on every PR? or are we doing this juts to test?
There was a problem hiding this comment.
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
| rev: v0.10.0.1 | ||
| hooks: | ||
| - id: shellcheck | ||
| args: ["--severity=warning"] |
There was a problem hiding this comment.
Not sure if apply but maybe a comment in the yaml might help for future reference.
| @@ -0,0 +1,46 @@ | |||
| # Dependency list for https://github.com/rapidsai/dependency-file-generator | |||
| files: | |||
There was a problem hiding this comment.
Is there any advantage to use rapids-dependency-file-generator at this stage of the project? why should we?
|
/merge |
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
Closes #89
rattler-buildfor builds, matching the direction RAPIDS is moving (Replace conda-build with rattler-build build-planning#47)VERSIONfile (so it can be referenced in bothpyproject.tomland therattler-buildrecipe)0.1.1(so we'll see packages get published)rapids-dependency-file-generatortest_python.shpyproject.toml