hermes - ✅(Solved) Fix [Bug]: uv.lock out of sync with pyproject.toml — `[google]` extra never locked, `uv lock --check` fails on a fresh clone [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17556Fetched 2026-04-30 06:46:49
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
labeled ×3cross-referenced ×2referenced ×1

Root Cause

13038dc7 added the [google] extra to pyproject.toml but didn't run uv lock afterwards. There's no CI step that runs uv lock --check on PRs, so the divergence merged silently.

The user-visible impact is partly hidden because setup.py --check for the google-workspace skill does an import test rather than a pip query, so users who got the old pip install fallback path still got working deps. But:

  • Nix / Homebrew packagers who consume uv.lock directly miss the deps.
  • uv sync from a fresh clone re-resolves and may pull a slightly newer wheel set than the committed lock, defeating reproducibility.
  • Any new contributor running uv lock --check (e.g. as a pre-commit hook) gets a spurious failure unrelated to their change.

Fix Action

Fixed

PR fix notes

PR #17644: chore(deps): regenerate uv.lock to include [google] extra (#17556)

Description (problem / solution / changelog)

Summary

Regenerate uv.lock so it matches pyproject.toml after the [google] extra was added in 13038dc7 but the lockfile was never updated.

The bug

On a clean checkout of origin/main:

$ uv lock --check
Resolved 258 packages in 737ms
The lockfile at \`uv.lock\` needs to be updated, but \`--check\` was provided.

pyproject.toml declares a [google] optional extra (with google-api-python-client, google-auth-oauthlib, google-auth-httplib2) and includes it in [all], but the lockfile's provides-extras manifest is missing google and none of the google packages are locked. Lock-pinned consumers (Nix flake, Homebrew formula, reproducible builds) hit an unexpected re-resolve on uv sync --extra google or uv sync --all-extras.

While we're here, the [matrix] extra's aiohttp-socks (added in 32d4048c6 for proxy support) was also never locked.

The fix

Run uv lock once and commit the result.

The diff is intentionally minimal — only what's required to get uv lock --check to pass:

  • Add google to the provides-extras manifest
  • Lock the three [google] direct deps + their transitive deps (google-api-core, google-auth, googleapis-common-protos, proto-plus, protobuf, httplib2, oauthlib, pyasn1, pyasn1-modules, requests-oauthlib, uritemplate)
  • Lock aiohttp-socks and python-socks for the [matrix] extra
  • exclude-newer rolls forward by 5 days, which is automatic under the existing exclude-newer-span = \"P7D\" policy

No package upgrades, no removals. 14 packages added, 0 removed, 0 changed versions.

Test plan

  • uv lock --check fails on origin/main (f45434d3c): The lockfile at \uv.lock` needs to be updated`
  • uv lock --check passes after this commit: Resolved 258 packages in 16ms (no further changes needed)
  • provides-extras now contains google
  • Diff stat: 1 file changed, 188 insertions(+), 8 deletions(-)
  • git diff shows zero existing-package version changes

Related

  • Fixes #17556
  • Follow-up to #13038dc74 (fix(skills): ship google-workspace deps as [google] extra)

Changed files

  • uv.lock (modified, +188/-8)

PR #17673: chore(deps): regenerate uv.lock and add CI uv lock --check (#17556)

Description (problem / solution / changelog)

What does this PR do?

The `[google]` optional extra was added to `pyproject.toml` in 13038dc7 but `uv.lock` was never regenerated to match, so on a fresh clone `uv lock --check` fails. Nix flakes, Homebrew formulae, and reproducible-build consumers that pin to the lockfile silently miss the deps the commit was meant to ship; `uv sync` from a clean clone re-resolves and may pick a newer wheel set than intended.

This PR is the two-part fix the issue recommends:

  1. Regenerate `uv.lock`. The lockfile now records the dependency closure for the `google` extra (`google-api-core`, `google-api-python-client`, `google-auth`, `google-auth-httplib2`, `google-auth-oauthlib`, plus `pyasn1`, `oauthlib`, `httplib2`, etc.) and `provides-extras` lists `google`. `uv lock --check` exits 0.
  2. Add a `uv lock --check` step to `.github/workflows/tests.yml` so the same drift can't merge silently again. The check runs immediately after `uv python install 3.11`, before the dependency install and test run, so a stale lockfile fails fast and doesn't burn the slower steps.

Related Issue

Fixes #17556

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • `uv.lock` regenerated against the current `pyproject.toml`. 188 lines added (5 `google-*` direct deps + transitive closure), 8 removed. `provides-extras` now lists `google`.
  • `.github/workflows/tests.yml`: new `Verify uv.lock is in sync with pyproject.toml` step that runs `uv lock --check`.

How to Test

  1. Locally: ``` git fetch && git checkout fix/17556-uv-lock-regen-and-ci-check uv lock --check ``` exits 0 with no output. (On main, the same command currently reports `The lockfile at uv.lock needs to be updated`.)
  2. CI: the new `Verify uv.lock is in sync with pyproject.toml` step runs in the `test` job and will fail any future PR that drifts `pyproject.toml` against `uv.lock`.
  3. Sanity-check the closure includes the google extra: ``` grep -c '^name = "google-' uv.lock # → 5 grep -A1 '^provides-extras' uv.lock # → includes "google" ```

This supersedes the stalled draft #17494 (which only does part 1) by adding the CI prevention the issue explicitly asks for.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (`fix(scope):`, `feat(scope):`, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run `uv lock --check` and it passes
  • I've added tests for my changes (the new CI step is the regression test for the underlying class of bug)
  • I've tested on my platform: macOS 15.x

Documentation & Housekeeping

  • I've updated relevant documentation (README, `docs/`, docstrings) — or N/A
  • I've updated `cli-config.yaml.example` if I added/changed config keys — or N/A
  • I've updated `CONTRIBUTING.md` or `AGENTS.md` if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Before this PR (on main): ``` $ uv lock --check Resolved 258 packages in 741ms The lockfile at `uv.lock` needs to be updated, but `--check` was provided. To update the lockfile, run `uv lock`. ```

After: ``` $ uv lock --check Resolved 258 packages in 10ms ```

Changed files

  • .github/workflows/tests.yml (modified, +3/-0)
  • uv.lock (modified, +188/-8)

Code Example

git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
uv lock --check

---

$ uv lock --check
Resolved 258 packages in 741ms
The lockfile at `uv.lock` needs to be updated, but `--check` was provided. To update the lockfile, run `uv lock`.
RAW_BUFFERClick to expand / collapse

Bug Description

On a fresh checkout of main (commit b2820cd2), uv lock --check reports the lockfile is stale. The [google] optional extra was added to pyproject.toml in 13038dc7 (PR landing the google-workspace skill packaging fix) but uv.lock was never regenerated to match — neither the package entries nor the provides-extras manifest list reflect the new extra.

This means anyone running uv sync --extra google (or uv sync --all-extras) from a clean clone triggers an unexpected re-resolve, and any caller that pins to the lockfile (Nix flake, Homebrew formula, reproducible build) gets a tree that doesn't include the deps the commit's own message claims it ships.

Steps to Reproduce

git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
uv lock --check

Expected Behavior

uv lock --check exits 0 with no output: the committed lockfile is consistent with pyproject.toml.

Actual Behavior

$ uv lock --check
Resolved 258 packages in 741ms
The lockfile at `uv.lock` needs to be updated, but `--check` was provided. To update the lockfile, run `uv lock`.

Concrete divergence:

  1. pyproject.toml declares the google extra (google-api-python-client>=2.100,<3, google-auth-oauthlib>=1.0,<2, google-auth-httplib2>=0.2,<1).
  2. uv.lock contains zero name = "google-*" package entries (grep -c '^name = \"google-' uv.lock0).
  3. uv.lock's provides-extras array is missing \"google\" (it lists vercel, dev, messaging, … but skips google).

After running uv lock locally, three new packages are added to uv.lock (google-api-core, google-api-python-client, google-auth, plus their transitive deps), the google entry appears in provides-extras, and --check passes.

Affected Component

Setup / Installation

Operating System

Linux (Arch, kernel 6.19) — but the bug is platform-independent; reproduces on any host with uv installed.

Python Version

3.11.14 (the install's pinned interpreter)

Hermes Version

Reproduces on main at b2820cd2. The bug was introduced by 13038dc7 (April 24, 2026) and has been latent ever since because nothing on the happy path (hermes update, hermes setup) runs uv lock --check.

Root Cause Analysis

13038dc7 added the [google] extra to pyproject.toml but didn't run uv lock afterwards. There's no CI step that runs uv lock --check on PRs, so the divergence merged silently.

The user-visible impact is partly hidden because setup.py --check for the google-workspace skill does an import test rather than a pip query, so users who got the old pip install fallback path still got working deps. But:

  • Nix / Homebrew packagers who consume uv.lock directly miss the deps.
  • uv sync from a fresh clone re-resolves and may pull a slightly newer wheel set than the committed lock, defeating reproducibility.
  • Any new contributor running uv lock --check (e.g. as a pre-commit hook) gets a spurious failure unrelated to their change.

Proposed Fix

Two parts:

  1. One-shot: run uv lock and commit the regenerated uv.lock. Adds three direct deps (google-api-core, google-api-python-client, google-auth) plus their transitive closure.

  2. Prevention: add uv lock --check to CI (e.g. in the existing GitHub Actions workflow that runs tests). It's a 1-second check and would have caught this at the 13038dc7 PR.

Happy to send a PR for both if that's useful.

extent analysis

TL;DR

Run uv lock and commit the regenerated uv.lock to resolve the stale lockfile issue.

Guidance

  • Verify the issue by running uv lock --check in a fresh clone of the repository.
  • Run uv lock to regenerate the uv.lock file, which should add the missing google extra and its dependencies.
  • Commit the updated uv.lock file to ensure consistency with pyproject.toml.
  • Consider adding uv lock --check to the CI pipeline to prevent similar issues in the future.

Example

No code snippet is necessary for this issue, as the solution involves running a specific command (uv lock) and committing the resulting changes.

Notes

The proposed fix has two parts: a one-time regeneration of the uv.lock file and a preventive measure to add a check to the CI pipeline. This should resolve the issue and prevent similar problems from occurring in the future.

Recommendation

Apply the proposed fix by running uv lock and committing the updated uv.lock file, and consider adding uv lock --check to the CI pipeline to prevent similar issues. This will ensure consistency between pyproject.toml and uv.lock and prevent unexpected re-resolves.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug]: uv.lock out of sync with pyproject.toml — `[google]` extra never locked, `uv lock --check` fails on a fresh clone [2 pull requests, 1 participants]