Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions manifest.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"version": "1",
"generated": "2026-10-23T02:19:26.101725+00:00",
"generated": "2026-10-23T02:28:13.259414+00:00",
"modules": {
"a2a": {
"description": "A2A (Agent-to-Agent Protocol) - Zero-dependency Python implementation",
Expand Down Expand Up @@ -423,8 +423,8 @@
"deps": [],
"tier": "subsystem",
"category": "text",
"last_updated": null,
"content_hash": "cbd2c82e7969bc7a74caebb60b6806690bd505c08a1393ea31f22afaae81c735"
"last_updated": "2026-10-22T21:18:10-05:00",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is the one hunk the PR body doesn't mention: the diff is not only tabulate. Regenerating the manifest also fills in semantic_search's missing last_updated and replaces a stale content_hash (cbd2c82e -> a2fe58bc) at an unchanged version 0.1.0.

That is the right call, and worth saying out loud because it looks like exactly the thing version-check exists to prevent - recording changed content under an unchanged version. It isn't, for one reason: semantic_search appears in no release tag (it landed after v2026.9.28), so the old hash was never published to anyone; _find_changed_modules treats an untagged module with a non-zero version as already bumped, which is why the base run didn't flag it either. Filling in null -> a real hash strictly improves what outdated/update can tell users.

Suggestion: one line in the PR body saying the manifest regeneration also completes the semantic_search entry, so the next reviewer isn't surprised by a second module in a "one-line" PR.

"content_hash": "a2fe58bc7b4c640e1bca7e06bd630bbf32295e4dda99d8e310b3530e4ce35740"
},
"semver": {
"description": "PEP 440 version parser and comparator -- zero dependencies, stdlib only",
Expand Down Expand Up @@ -520,7 +520,7 @@
"files": [
"tabulate/tabulate.py"
],
"version": "0.1.1",
"version": "0.1.2",
"deps": [],
"tier": "medium",
"category": "terminal",
Expand Down
2 changes: 1 addition & 1 deletion tabulate/tabulate.py
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# /// zerodep
# version = "0.1.1"
# version = "0.1.2"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Worth knowing what this line does and doesn't buy, since it is the whole reason the gate now passes.

_find_changed_modules has no tag containing 0.1.2, so it falls into the "already bumped" branch: it finds the newest tag holding this module (0.1.1), notes the version differs, and reports up-to-date without comparing content at all. I proved that by appending a comment to tabulate/tabulate.py at this head and re-running:

$ printf '\n# reviewer teeth probe\n' >> tabulate/tabulate.py
$ python -m zerodep version-check --strict   ->  exit 0, tabulate 0.1.2 up-to-date

So until a v* tag containing 0.1.2 exists, further edits to tabulate ride along uncaught. That is the intended double-bump guard rather than a defect, and the check's real teeth are visible on master, where it does compare against the released 0.1.1 content and fails. But "the check now passes" here means "the version moved past the last tag", not "the recorded content was verified" - worth a sentence in cmd_version_check's docstring or CONTRIBUTING so nobody reads a green run as content verification.

Related, minor: python -m zerodep manifest at this head rewrites seven last_updated values from ...Z to ...+00:00 (same instant, different serialisation), so regeneration is not byte-identical to the committed file. Harmless where it matters - release.yml runs manifest and then git add -A, so that churn simply lands in the release commit - but it means a future "manifest is up to date" CI check would need to compare parsed timestamps, not bytes.

# deps = []
# tier = "medium"
# category = "terminal"
Expand Down
Loading