Skip to content

chore(deps-dev): bump pdoc from 15.0.4 to 16.0.0 #1594

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
+15 −5
Open

chore(deps-dev): bump pdoc from 15.0.4 to 16.0.0 #1594

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ dev = [
"opentelemetry-instrumentation-threading>=0.59b0,<1",
]
docs = [
Copy link
Copy Markdown

@claude claude bot Mar 30, 2026

Choose a reason for hiding this comment

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

🟡 The pdoc version constraint was updated to >=15.0.4,<17 but the lower bound was not updated to >=16.0.0, meaning environments that install without the lock file (e.g., pip install langfuse[docs]) could resolve to pdoc 15.x instead of the intended 16.x. Consider changing the constraint to pdoc>=16.0.0,<17 to match the PR's intent.

Extended reasoning...

What the bug is: The PR bumps pdoc from 15.0.4 to 16.0.0, and correctly updates the lock file to pin pdoc 16.0.0. However, the version constraint in pyproject.toml was changed from >=15.0.4,<16 to >=15.0.4,<17 — only widening the upper bound — rather than >=16.0.0,<17. This means the lower bound still allows any pdoc 15.x release to satisfy the constraint.

The specific code path: In pyproject.toml line 38, the docs extra dependency is declared as pdoc>=15.0.4,<17. A resolver that sees this constraint (without the lock file) is free to choose pdoc 15.0.4 as a valid solution.

Why existing code doesn't prevent it: The uv.lock file pins pdoc to exactly 16.0.0, so any uv sync or uv run invocation respects the lock and gets 16.0.0. However, anyone running pip install "langfuse[docs]" (a common workflow for users installing the docs extra manually, or in CI pipelines not using uv) bypasses the lock file entirely and relies solely on the pyproject.toml constraint. With >=15.0.4,<17, pip could resolve to 15.x.

Impact: pdoc 16.0.0 is a major version release with meaningful changes: it adds markdown2 as a new dependency, drops Python 3.9 support, and changes templating behavior. Running with pdoc 15.x versus 16.x would produce different documentation output and could silently fail to include markdown2. That said, this is a docs-only dev dependency, so production users are entirely unaffected.

How to fix it: Change line 38 in pyproject.toml from pdoc>=15.0.4,<17 to pdoc>=16.0.0,<17.

Step-by-step proof:

  1. A user runs pip install "langfuse[docs]" (not using uv, no lock file honored).
  2. pip sees the constraint pdoc>=15.0.4,<17.
  3. pip resolves the latest compatible version — normally 16.0.0 — but if 16.0.0 is yanked or if the user has a conflicting constraint pinning an older version, pip could legitimately choose any pdoc 15.x release (e.g., 15.0.4).
  4. The installed pdoc 15.x lacks the markdown2 dependency and has different rendering behavior compared to 16.x.
  5. The developer or CI system gets unexpected documentation output without any error indicating the wrong version is installed.

Addressing the refutation: The refutation correctly notes this is standard Dependabot behavior — Dependabot typically only widens the upper bound. However, "standard Dependabot behavior" and "correct constraint" are different things. The constraint >=15.0.4,<17 is technically imprecise for a PR whose stated goal is to adopt pdoc 16.0.0. This is a nit rather than a blocking issue because the lock file protects most real workflows, but tightening the lower bound is a small, low-risk improvement worth noting.

"pdoc>=15.0.4,<16",
"pdoc>=15.0.4,<17",
]

[build-system]
Expand Down
18 changes: 14 additions & 4 deletions uv.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading