Skip to content

Conversation

@avendesora
Copy link
Owner

@avendesora avendesora commented Aug 21, 2025

Description

Switch to using uv wherever possible, including in test, build and release steps

Checklist:

  • I have read the CONTRIBUTING document.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have run pre-commit locally prior to submission and fixed any errors/warnings.
  • I have run tests locally prior to submission and they are passing.
  • I have added necessary documentation (if appropriate).
  • I have updated the README (if appropriate).
  • I have updated the CHANGELOG (if appropriate).
  • I have updated the version number (if appropriate).
  • I have updated the requirements (if appropriate).

Summary by Sourcery

Migrate project from flit to uv for building, testing, and publishing; update configuration, documentation, and CI workflows accordingly.

Enhancements:

  • Replace flit-based build and metadata configuration with uv in pyproject.toml
  • Consolidate development, documentation, and test dependencies into uv dependency-groups
  • Remove legacy requirements-* files
  • Update docs Makefile to run Sphinx through uv

Build:

  • Switch build-backend from flit_core to uv_build
  • Adapt project metadata and dependency declarations for uv

CI:

  • Add GitHub Actions release workflow to build and publish via uv
  • Update README badges to reflect uv-based workflows and tooling

Documentation:

  • Update README badges and changelog to document the switch to uv

@sourcery-ai
Copy link
Contributor

sourcery-ai bot commented Aug 21, 2025

Reviewer's Guide

This PR migrates the project’s packaging, testing, documentation, and release processes from flit to uv by overhauling the build configuration in pyproject.toml, updating documentation commands and badges, adding a uv-based release workflow, and cleaning up legacy artifacts.

Entity relationship diagram for dependency groups in pyproject.toml

erDiagram
    PROJECT ||--o{ DEPENDENCY_GROUP : has
    DEPENDENCY_GROUP {
        string name
        string[] dependencies
    }
    PROJECT {
        string name
        string version
        string requires-python
    }
Loading

Flow diagram for documentation build process using uv

flowchart TD
    DocsMakefile[docs/Makefile]
    UVRun[uv run --project=.. --group docs --locked sphinx-build]
    SphinxBuild[sphinx-build]
    DocsMakefile --> UVRun --> SphinxBuild
Loading

File-Level Changes

Change Details Files
Migrate build backend from flit to uv and define uv configuration
  • Replace flit_core with uv_build in [build-system]
  • Add [tool.uv] section with build-backend settings
  • Move project metadata under [project] and set version
  • Define dependency-groups (dev, docs, test)
  • Lock dependencies via uv.lock
pyproject.toml
uv.lock
Refresh README badges and update docs Makefile to use uv
  • Update CI and code quality badge URLs to uv-based workflows
  • Switch Makefile’s SPHINXBUILD to invoke uv run for docs
  • Add new badges for CodeQL and Sourcery
README.md
docs/Makefile
Add GitHub Actions release workflow using uv
  • Create release.yml to trigger on published releases
  • Install uv and use uv commands for python install, build, version check, and publish
.github/workflows/release.yml
Clean up legacy flit metadata and requirements files
  • Remove [tool.flit.metadata] section
  • Delete requirements.txt, requirements-dev/test/docs files
pyproject.toml
requirements-dev.txt
requirements-docs.txt
requirements-test.txt
requirements.txt
Document migration in CHANGELOG and bump version
  • Record switch from flit to uv and CI workflow updates
  • Increment project version to 0.14.0
CHANGELOG.md
pyproject.toml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@codacy-production
Copy link

codacy-production bot commented Aug 21, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
+0.00%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (9fe0cfb) 1875 1875 100.00%
Head commit (506341d) 1875 (+0) 1875 (+0) 100.00% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#204) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

@avendesora avendesora marked this pull request as ready for review August 21, 2025 23:53
Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

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

Hey there - I've reviewed your changes and they look great!

Blocking issues:

  • An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `.github/workflows/release.yml:29` </location>
<code_context>
+      - name: Verify version matches release tag
+        shell: bash
+        run: |
+          TAG="${GITHUB_EVENT_NAME:-release}"
+          # On release event, the tag name is here:
+          TAG_NAME="${{ github.event.release.tag_name }}"
+          VERSION="$(uv version --short)"
+          echo "tag=${TAG_NAME}  pyproject=${VERSION}"
+          # Accept tags like v1.2.3 -> 1.2.3
+          TAG_STRIPPED="${TAG_NAME#v}"
+          test "${VERSION}" = "${TAG_STRIPPED}"
+
+      - name: Build distributions
</code_context>

<issue_to_address>
Release workflow strictly enforces version/tag match, which may block releases if tags are misnamed.

Consider providing clear error messages or instructions for maintainers when the version/tag check fails to help resolve formatting issues quickly.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
      - name: Verify version matches release tag
        shell: bash
        run: |
          TAG="${GITHUB_EVENT_NAME:-release}"
          # On release event, the tag name is here:
          TAG_NAME="${{ github.event.release.tag_name }}"
          VERSION="$(uv version --short)"
          echo "tag=${TAG_NAME}  pyproject=${VERSION}"
          # Accept tags like v1.2.3 -> 1.2.3
          TAG_STRIPPED="${TAG_NAME#v}"
          test "${VERSION}" = "${TAG_STRIPPED}"
=======
      - name: Verify version matches release tag
        shell: bash
        run: |
          TAG="${GITHUB_EVENT_NAME:-release}"
          # On release event, the tag name is here:
          TAG_NAME="${{ github.event.release.tag_name }}"
          VERSION="$(uv version --short)"
          echo "tag=${TAG_NAME}  pyproject=${VERSION}"
          # Accept tags like v1.2.3 -> 1.2.3
          TAG_STRIPPED="${TAG_NAME#v}"
          if [ "${VERSION}" != "${TAG_STRIPPED}" ]; then
            echo "::error::Version mismatch detected!"
            echo "Release tag: ${TAG_NAME}"
            echo "pyproject.toml version: ${VERSION}"
            echo ""
            echo "To fix:"
            echo " - Ensure the release tag matches the version in pyproject.toml (e.g., tag 'v${VERSION}')"
            echo " - If the tag is incorrect, delete and recreate the release with the correct tag."
            exit 1
          fi
>>>>>>> REPLACE

</suggested_fix>

### Comment 2
<location> `pyproject.toml:21` </location>
<code_context>
+    { name = "Nathan Patton", email = "npatton@gmail.com" }
+]
+readme = "README.md"
+license = { text = "MIT" }
 classifiers = [
     "Intended Audience :: Information Technology",
</code_context>

<issue_to_address>
License field uses inline text rather than SPDX identifier.

Use the SPDX identifier format for the license field to ensure compatibility with PyPI and related tools.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
license = { text = "MIT" }
=======
license = "MIT"
>>>>>>> REPLACE

</suggested_fix>

## Security Issues

### Issue 1
<location> `.github/workflows/release.yml:21` </location>

<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.

*Source: opengrep*
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

avendesora and others added 6 commits August 21, 2025 21:59
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
@avendesora avendesora merged commit ba3fc6d into main Nov 9, 2025
9 checks passed
@avendesora avendesora deleted the switch-to-uv branch November 9, 2025 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants