Migrate to uv and integrate PSR for automated releases#218
Conversation
- Replace Poetry with uv for dependency management and packaging - Add pre-commit hooks for ruff (lint/format) and commitizen (commit-msg) - Configure Python Semantic Release (PSR) for automated versioning - Add commitizen for local commit message validation - Create unified CI workflow with lint, test, and release jobs - Add Justfile for common development workflows
jondricek
left a comment
jondricek
left a comment
There was a problem hiding this comment.
Ok, here's my overarching review. It is definitely going in the right direction but has a few edges that need sanding off.
.github/workflows/ci.yml
Outdated
|
|
||
| - name: Check commit messages | ||
| run: | | ||
| if [ "${{ github.event_name }}" = "pull_request" ]; then |
There was a problem hiding this comment.
I want to make sure we make it as easy as possible for external contributors to contribute. This makes me think of this FAQ from the Conventional Commits site.
Do all my contributors need to use the Conventional Commits specification?
No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.
I think it might be better to squash commits from pull requests somehow instead and only validate commit messages that we ourselves write, to not make it an overly arduous process for external contribs.
There was a problem hiding this comment.
Great idea. Just pushed a change to (hopefully) enable this:
# For PRs, validate the PR title (which becomes the squash commit message).
# This avoids burdening external contributors with conventional commit enforcement
# on every individual commit. See: https://www.conventionalcommits.org/en/v1.0.0/
#
# For pushes to main, validate the final commit message (the squash merge commit)
# using commitizen as a safety net.
commitlint:
runs-on: ubuntu-latest
steps:
# PR: validate PR title follows conventional commit format
- name: Validate PR title
if: github.event_name == 'pull_request'
uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
# For work-in-progress PRs you can typically use draft pull requests from GitHub.
# This action allows us to use the special "[WIP]" prefix to indicate a draft state
# without actually flagging the PR as a draft.
# Example:
# `[WIP] feat: Add support for Node.js 18` <--- will not be validated!
wip: true
# Push to main: validate the squash merge commit message directly
- name: Checkout
if: github.event_name == 'push'
uses: actions/checkout@v6
with:
fetch-depth: 2
- name: Install uv
if: github.event_name == 'push'
uses: astral-sh/setup-uv@v7
with:
version: "latest"
- name: Install Python and dependencies
if: github.event_name == 'push'
run: |
uv python install 3.11
uv sync --all-extras
- name: Validate commit message
if: github.event_name == 'push'
run: uv run cz check --rev-range HEAD~1..HEADThe first step uses an off the shelf GH action, amannn/action-semantic-pull-request@v5 to ensure that the pull request title match the Conventional Commits spec. It only runs on pull_request events.
The latter four steps run on push events, and will check the final/actual commit for pushes to main as a safety measure.
We'll probably want to configure the repo to only allow squash merges (or at least default to them):
- Settings --> General --> Pull Requests → check only "Allow squash merging" and set the default commit message to "Pull request title".
This will ensure the conventional PR title always becomes the merge commit message that PSR parses.
(We'll of course need to test this.)
.readthedocs.yaml
Outdated
| - pip install poetry | ||
| post_install: | ||
| - VIRTUAL_ENV=$READTHEDOCS_VIRTUALENV_PATH poetry install --with docs | ||
| commands: |
There was a problem hiding this comment.
according to the readthedocs docs, we should lean towards using build.jobs stuff instead
https://docs.readthedocs.com/platform/stable/config-file/v2.html#build-commands
we recommend using build.jobs instead
There was a problem hiding this comment.
I think I implemented build.jobs correctly but it's possible I assigned the commands to the incorrect build stages.
https://docs.readthedocs.com/platform/stable/builds.html
https://docs.readthedocs.com/platform/stable/build-customization.html
A few more findings
|
jondricek
left a comment
jondricek
left a comment
There was a problem hiding this comment.
Oh, interesting - it didn't share these comments yet
Co-authored-by: Jared Ondricek <90368810+jondricek@users.noreply.github.com>
Co-authored-by: Jared Ondricek <90368810+jondricek@users.noreply.github.com>
Co-authored-by: Jared Ondricek <90368810+jondricek@users.noreply.github.com>
- Still checks the actual commit for pushes to main - Uses amannn/action-semantic-pull-request action Will need to configure the repo to only allow squash merges
…k-python into semantic-release
Co-authored-by: Jared Ondricek <90368810+jondricek@users.noreply.github.com>
Co-authored-by: Jared Ondricek <90368810+jondricek@users.noreply.github.com>
This is needed by amann/action-semantic-pull-request to validate the PR title against Conventional Commit syntax rules.
- pr-title.yml runs on pull_request_target and checks the PR title - ci.yml::commitlint runs on push to main only and expects commits to be squashed - ci.yml::[lint,test] run on push + pull_request for all
…k-python into semantic-release
|
2 participants
Changes
poetrywithuvpre-commitpre-commitrunsruff-formatfor formatting filespre-commitrunscommitizenfor enforcing conventional commit syntax before commits are acceptedsemantic-releasetoolsemantic-releasecan technically be used within any language environment, it relies on community plugins, and there are only two plugins listed on the official plugins page that support Python oruv; neither of which have many GitHub Stars.commitizen. This is the equivalent of usingsemantic-releaseandcommitlintin our other JS-oriented projects.uvand PSR (un-tested)Justfilefor streamlining common functions (equivalent ofnpm run ...just ...)