build: pin Python deps with uv.lock for reproducible releases - #644
Open
fwh888 wants to merge 1 commit into
Open
build: pin Python deps with uv.lock for reproducible releases#644fwh888 wants to merge 1 commit into
fwh888 wants to merge 1 commit into
Conversation
The Python side of the project had no lockfile: every install (dev venvs, CI, and the desktop release builds) resolved dependencies fresh from PyPI at build time. Two DMG/MSI builds on different days could ship different dependency versions, with no record of what actually shipped - making vulnerability triage of released artifacts guesswork. - Add uv.lock (102 packages, core + all extras) committed to the repo. - Add a 'build' extra (pyinstaller + typer) so the build-time-only deps are pinned too, instead of being installed ad-hoc in the build scripts. - Switch setup_dev_env.sh, build_dmg.sh, build_windows.ps1, CI and the release workflow to 'uv sync --frozen' so every install path resolves the exact pinned set. Verified: uv sync --frozen installs cleanly and the pytest suite passes (1946 passed; the 8 bedrock failures are local-only, boto3 not installed).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #517.
The Python side of the project had no lockfile: every install (dev venvs, CI, and the desktop release builds) resolved dependencies fresh from PyPI at build time. Two DMG/MSI builds on different days could ship different dependency versions, with no record of what actually shipped — making vulnerability triage of released artifacts guesswork.
What this does
uv.lock(102 packages, core + all extras) committed to the repo, so every install path resolves the exact same dependency set.buildextra (pyinstaller+typer) so the build-time-only deps are pinned too, instead of being installed ad-hoc in the build scripts.uv sync --frozen:packaging/setup_dev_env.sh(dev bootstrap)packaging/build_dmg.sh/packaging/build_windows.ps1(desktop builds).github/workflows/ci.yml(pytest job).github/workflows/release.yml(sidecar venv provisioning)Why uv
The other three trees in this repo already do this right:
surfaces/gui/package-lock.json,stt/Cargo.lock,surfaces/gui/src-tauri/Cargo.lockare all committed. Python was the one gap.uvis the fastest resolver and its lockfile is a single committed file with hashes for every package.Verification
uv sync --frozeninstalls cleanly from the lockfile.uv lock --checkpasses against the committed lockfile.Follow-up (not in this PR)
A CI step that scans the lockfile (e.g.
osv-scanner -L uv.lock) would catch dependency regressions at PR time — happy to add it in a follow-up if maintainers want it.