Skip to content

Pin pymdown-extensions back to 11.0#3106

Open
maxisbey wants to merge 1 commit into
mainfrom
chore/pymdown-extensions-11.0
Open

Pin pymdown-extensions back to 11.0#3106
maxisbey wants to merge 1 commit into
mainfrom
chore/pymdown-extensions-11.0

Conversation

@maxisbey

Copy link
Copy Markdown
Contributor

The relock in #3073 picked up pymdown-extensions 11.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 are zensical>=10.21.3 and mkdocstrings>=6.3), so this rolls the transitive pin back to 11.0 to match that policy.

Lockfile-only; uv lock --check passes.

AI Disclaimer

@maxisbey maxisbey marked this pull request as ready for review July 16, 2026 16:43

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

No issues found across 1 file

Re-trigger cubic

@claude claude Bot left a comment

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.

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.yml sets cooldown: 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
@maxisbey maxisbey force-pushed the chore/pymdown-extensions-11.0 branch from 3ec9ee1 to 759071c Compare July 16, 2026 17:30

@claude claude Bot left a comment

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.

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-extensions entry in uv.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.

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.

1 participant