Conversation
| if v_p.is_prerelease: | ||
| # For alpha releases, only major version must match | ||
| assert v_c.release[0] == v_p.release[0] | ||
| else: # pragma: no cover |
There was a problem hiding this comment.
shouldn't the no cover comment be on the prerelease branch, so when we switch back to that the coverage goes back up?
There was a problem hiding this comment.
Well, the tricky part is that we fail on anything less than 100% coverage. Let me try another approach.
There was a problem hiding this comment.
Just updated. What do you think of this approach? We always at least test the major version and that's included in coverage.
For full releases, we also always check the minor version for mismatch (which is what we want this test for), but we just have this branch not contribute to coverage, which I think is OK.
CI still fails if we fall below 100% coverage.
There was a problem hiding this comment.
I see, if we enforce 100% does that mean that CI would have required you to adjust the no cover comment in order to release? If so then the original approach is fine since there is no risk of forgetting to cover those lines upon release.
There was a problem hiding this comment.
Yeah, with the previous version, we would have had to switch.
With the current version, we don't have to switch. We pay for it by skipping coverage on that line (for release builds), but I think that's OK. We're still running the test, and we don't get much benefit from computing coverage for that specific line.
| 'src/h3lib', | ||
| 'docs', | ||
| 'dev_notes.md', | ||
| 'makefile', |
There was a problem hiding this comment.
do we need to exclude justfile here?
There was a problem hiding this comment.
...and found a few others that would clean up the sdist.
3 participants
Motivated by #482, I was thinking of making an alpha release to provide early access to the new cells-to-poly functionality.
This would also have the benefit of testing out upstream C library changes in at least one binding ahead of the final release.
This change ended up focusing on modernizing the library tooling. To isolate any issues due to that modernization, I'll add the
cellsToMultiPolygonin a separate alpha release.Summary
Alpha release to prepare for testing
h3libdraft v4.5 changes (likecellsToMultiPolygon). This PR focuses on modernizing the build and CI tooling.h3lib update
Bumps
h3libto an unreleased commit with changes planned for v4.5. The h3-py version is set to4.5.0a1to reflect this, and the version check test is relaxed for prerelease versions.Drop Python 3.8 and 3.9
Both reached end-of-life (3.8 in Oct 2024, 3.9 in Oct 2025). Dropping them also unblocks, for example,
sphinx>=7.3.3(which requires Python 3.9). Sinceuvresolves dependencies across all supported Python versions, keeping 3.8 inrequires-pythonmade it impossible to resolve the docs dependencies alongside dev dependencies.In general, going forward, dropping EOL Python versions will make it easier to support and develop h3-py.
Python 3.14 is now documented as supported in
pyproject.toml.Migrate to uv and justfile
Replaces the
pipandmakefileworkflow withuvand ajustfile:uvspeeds up build time significantly over the previouspipworkflowjustfilefor common dev commands (just test,just lint,just docs)CI modernization
actions/setup-pythontoastral-sh/setup-uvjustfilecommands rather than duplicating test/lint logicpipx runtouvx