build: move to the uv build backend and add a test workflow - #223
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #223 +/- ##
============================================
+ Coverage 73.07% 100.00% +26.92%
============================================
Files 25 2 -23
Lines 1545 6 -1539
============================================
- Hits 1129 6 -1123
+ Misses 416 0 -416 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
3.0 absorbs the bblocks-data-importers codebase, which locks with uv. Converging the build here first keeps the move itself a code change. The backend is uv_build, which is what the family contract in #208 asks for. The repo had no test workflow, only a release one, so nothing ran on a pull request. tests.yml runs the matrix the importers already use, plus a packaging job that asserts the built wheel ships bblocks/__init__.py and no bblocks/data_importers/ path. That assertion is load-bearing. Once the importers move in, bblocks and the retiring bblocks-data-importers distribution have to own disjoint file paths. Where both claim bblocks/data_importers/__init__.py, pip installs bblocks first and then deletes that file while uninstalling the older distribution. The install then imports nothing and pip check reports it healthy. uv scopes the same uninstall correctly, so CI alone would miss it. release.yaml ran poetry, which is gone. It builds with uv and publishes through PyPI trusted publishing. The publisher has to be configured on PyPI before the next release will work, against the pypi environment named here. setup-uv is pinned to an exact release because the action stopped publishing floating major tags at v8. Its v10 also disables the cache on release events, which is the trigger release.yaml uses, so the older pin would have published without that protection. Co-authored-by: Claude <noreply@anthropic.com>
f85cb43 to
fca5f3a
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fca5f3a13b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| permissions: | ||
| id-token: write |
There was a problem hiding this comment.
On every release run, declaring only id-token: write sets all unspecified GITHUB_TOKEN permissions to none, including contents; consequently, the actions/checkout step cannot fetch the repository. Add contents: read alongside the OIDC permission so the job can reach the build and publish steps.
Useful? React with 👍 / 👎.
| @@ -22,12 +22,22 @@ all = [ | |||
| "bblocks-datacommons-tools>=0.0.2,<0.1.0" | |||
| ] | |||
|
|
|||
There was a problem hiding this comment.
After moving dependency management to uv.lock and running CI with uv sync, CONTRIBUTING.md lines 59–64 still say dependencies are managed with Poetry and direct contributors to run poetry install. Poetry does not consume the committed uv lock, so contributors following the documented setup get a separately resolved environment rather than the versions exercised by CI; update the setup and test commands to use uv.
Useful? React with 👍 / 👎.
1 participant
Part of #209.
bblocks 3.0 absorbs the bblocks-data-importers codebase, which locks with uv. Converging the build before the move keeps that change a code change instead of a code-and-toolchain change. The backend is uv_build, which is what the family contract in #208 asks for. poetry.lock goes, uv.lock replaces it.
The repo had no test workflow, only a release one, so nothing ran on a pull request. tests.yml runs the OS and Python matrix the importers already use, and adds a packaging job that asserts the built wheel ships bblocks/init.py and no path under bblocks/data_importers/.
That assertion is why this PR comes first. Once the importers move in, bblocks and the retiring bblocks-data-importers distribution have to own disjoint file paths. If both claim bblocks/data_importers/init.py, pip installs bblocks first and then deletes that file while uninstalling the older distribution. The result imports nothing while pip check reports it healthy. I checked this by building both layouts and installing them for real. pip destroys the file under both uninstall orderings, and uv scopes the same uninstall correctly, so a uv-only CI would never have caught it.
release.yaml ran poetry, which this PR removes, so it now builds with uv and publishes through PyPI trusted publishing rather than a long-lived API token. The next release will fail until the bblocks project on PyPI has a trusted publisher configured against the pypi environment named in the workflow. setup-uv is pinned to an exact release because the action stopped publishing floating major tags at v8, and its v10 disables the cache on release events, which is the trigger this workflow uses.
The codecov step runs with fail_ci_if_error false because this repo has no CODECOV_TOKEN secret. Adding the secret would let that flip.
The pull_request trigger carries no base-branch filter. Filtering on main only matches PRs targeting main, so in a stack every PR except this one would run no tests and show a reviewer no checks at all.
Testing: pytest, ruff check, ruff format --check and uv build all pass on this commit, and the built wheel contains bblocks/init.py and no data_importers path.