Pin pymdown-extensions back to 11.0#3106
Conversation
There was a problem hiding this comment.
LGTM — lockfile-only rollback of a transitive docs dependency (pymdown-extensions 11.0.1 → 11.0) to comply with the repo's 14-day dependency cooldown.
What was reviewed
- Verified the new sdist/wheel sha256 hashes and upload timestamps match PyPI's published records for pymdown-extensions 11.0 exactly.
- Confirmed the cooldown rationale:
.github/dependabot.ymlsetscooldown: default-days: 14, and 11.0.1 was released 2026-07-02, inside that window at the time of the #3073 relock. - Checked both lockfile dependents (
zensical,mkdocstrings) — their constraints are satisfied by 11.0.
Extended reasoning...
Overview
This PR touches only uv.lock, rolling the transitive pin of pymdown-extensions from 11.0.1 back to 11.0. No source code, no direct dependency constraints, and no CI configuration are modified. The change swaps one version's sdist/wheel URLs and hashes for the prior release's.
Security risks
The main risk in a hand-edited lockfile change is a tampered hash or URL pointing at a malicious artifact. I fetched the PyPI JSON metadata for pymdown-extensions 11.0 and confirmed both the sdist and wheel sha256 digests, file sizes' plausibility, and upload timestamps in the diff match PyPI's canonical records exactly. The URLs are standard files.pythonhosted.org paths. No other risk surface exists — this is a docs-toolchain dependency (used by zensical/mkdocstrings), not a runtime dependency of the mcp package.
Level of scrutiny
Low-to-moderate: lockfile-only changes deserve hash verification (done) but no logic review. The stated rationale checks out — .github/dependabot.yml applies a 14-day cooldown to dependency updates, and 11.0.1 (released 2026-07-02) was inside that window when #3073 relocked. Both dependents that pull in pymdown-extensions (zensical, mkdocstrings) are satisfied by 11.0, so the rollback is consistent; the author reports uv lock --check passes, which CI's lock-consistency pre-commit check also enforces.
Other factors
The bug hunting system found no issues, and there are no outstanding reviewer comments on the PR. The change is small, self-contained, mechanical, and aligned with the repo's documented dependency policy (AGENTS.md explicitly discourages unnecessary dependency bumps). This fits squarely in the approvable category.
The relock in #3073 picked up 11.0.1 the week it was released, ahead of the 14-day cooldown we apply to dependency updates. Nothing requires the patch release (constraints are >=10.21.3 / >=6.3), so roll the transitive pin back to 11.0. No-Verification-Needed: lockfile-only transitive pin change
3ec9ee1 to
759071c
Compare
There was a problem hiding this comment.
LGTM — lockfile-only rollback of a transitive pin (pymdown-extensions 11.0.1 → 11.0), consistent with the dependency-cooldown policy.
What was reviewed
- Verified the diff touches only the
pymdown-extensionsentry inuv.lock; no other packages or version constraints change. - Cross-checked the new sdist and wheel sha256 hashes against PyPI for pymdown-extensions 11.0 — both match exactly, so the lock entry points at the genuine release artifacts.
- Confirmed nothing in the diff raises or lowers any
>=floors, matching the stated rationale that no direct constraint requires 11.0.1.
Extended reasoning...
Overview
This PR changes a single file, uv.lock, rolling the transitive pin of pymdown-extensions from 11.0.1 back to 11.0. The rationale is that a prior relock (#3073) picked up the 11.0.1 patch release within days of its publication, ahead of the 14-day cooldown the repo applies to dependency updates via dependabot. No direct constraint requires the patch release, so the rollback is policy alignment only.
Security risks
Lockfile changes are supply-chain-sensitive because they swap package URLs and hashes. I verified the new entry against the PyPI JSON API for pymdown-extensions 11.0: the sdist hash (8269cef0…) and wheel hash (fbc4acb6…) both match the official release artifacts on files.pythonhosted.org exactly. Rolling back to a slightly older release published 2026-06-23 carries no meaningful new risk; if anything it aligns with the cooldown policy designed to mitigate freshly-published-package risk.
Level of scrutiny
Low. This is a docs-toolchain dependency (pymdown-extensions is pulled in by the mkdocs/zensical documentation stack), not runtime SDK code. The change is mechanical, one package, one version step, and uv lock --check consistency is enforced by pre-commit/CI. The bug hunting system found no issues, and there is nothing here a human reviewer would need to weigh in on beyond the hash verification I performed.
Other factors
The PR description is accurate and self-consistent with the diff. The timeline shows no outstanding reviewer comments. The local repo's HEAD already contains an identically-titled commit, consistent with this being a straightforward, uncontroversial change.
The relock in #3073 picked up
pymdown-extensions11.0.1 the week it was released — ahead of the 14-day cooldown we apply to dependency updates in.github/dependabot.yml. Nothing requires the patch release (the actual constraints arezensical>=10.21.3andmkdocstrings>=6.3), so this rolls the transitive pin back to 11.0 to match that policy.Lockfile-only;
uv lock --checkpasses.AI Disclaimer