Repository navigation
⬆️ Drop sphinx-codelinks' click cap: it pinned a package nothing uses - #1943
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1943 +/- ##
=======================================
Coverage 91.69% 91.70%
=======================================
Files 129 129
Lines 18155 18152 -3
=======================================
- Hits 16648 16647 -1
+ Misses 1507 1505 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
chrisjsewell
added a commit
that referenced
this pull request
Sep 15, 2026
…ioning-strategy increase-if-necessary for the uv ecosystem (#1942) One line in `.github/dependabot.yml`: `versioning-strategy: increase-if-necessary` for the uv ecosystem, with the reason written next to it. (First opened as `lockfile-only`; changed after weighing the cost below.) ### Why Dependabot's default strategy for a project with a lockfile is `increase`: it rewrites the manifest requirement to match the new release even when the requirement already allows it. Every specifier in this workspace's manifests is a decision, so that is the wrong strategy here. Floors are series (`ty~=0.0.80`, `types-docutils~=0.20.0`), caps carry their reason as a comment, and the intra-workspace floors are moved by `propagate_floors.py` at release time. The 2026-09 batch, #1940, is the measurement. As proposed it raised sphinx-needs' `matplotlib>=3.3.0`, the floor of the user-facing `plotting` extra, to `>=3.11.2`, the newest release, although the floor already allowed it. An earlier batch rewrote `~=0.20.0` as `>=0.20,<0.24`, which is why the `types-docutils` ignore rule exists. ### What changes With `increase-if-necessary`, a requirement that already allows the new release is left alone and only the lock moves. A release outside a range still produces a pull request that widens the range. That second half is kept on purpose. 44 of the 97 external specifiers in these manifests carry a cap or a series, many of them runtime caps on sphinx-needs' user-facing dependencies (`jsonschema-rs<0.54`, `requests-file<4`, `pydata-sphinx-theme<0.20`, `sphinx-immaterial<0.14`, `pytest<10`, ...). The widening pull request is the one signal that a new major of one of them exists, and its review is where a stale reason comment or a widened `~=` series gets re-expressed by hand. `lockfile-only` was considered and rejected for exactly this: it never edits a manifest, but it also never proposes such a release, so the workspace would sit on an old series until a user noticed. The `ignore` rules stay and are unaffected: they stop lock-only updates that the manifests *would* allow but the test matrix and the typing floor do not want (a sphinx minor inside `>=7.4,<10`, a `types-docutils` minor inside its series). The member-name ignores stay for their own reason (dependabot-core#14004). ### Applied to last night's batch Under this strategy #1940 would have been: matplotlib and uv as lock-only updates, and the click bump as a widening of `click < 8.2` for review. That cap turned out to pin a package nothing uses, and #1943 drops it deliberately. ### Caveat The options reference lists `uv` as supporting `versioning-strategy` and lists the values for the option as a whole; it notes an ecosystem may not support every value. If uv does not accept this one, dependabot rejects the configuration visibly on its settings page rather than doing anything silently, and `lockfile-only` is the fallback. ### Checked `uv run poe lint` 8/8 (yamlfmt included). No lock change: the file is configuration only.
chrisjsewell
added a commit
that referenced
this pull request
Sep 16, 2026
…ten down (#1944) Reverts #1942's `versioning-strategy: increase-if-necessary` and records, in two places, what was measured and what a reviewer does instead. ### What went wrong with #1942 After the merge, every dependabot job for this repository errored with "Dependabot can't resolve your Python dependency files": ``` No solution found when resolving dependencies for split (… included: sphinx-needs-workspace[group:typing] …): Because sphinx>=7.4.0,<=7.4.7 depends on docutils>=0.20,<0.22 and sphinx-needs-workspace:typing depends on docutils==0.23, … ``` The mechanism, from dependabot-core's python update checker (which uv reuses): every strategy except `lockfile-only` *unlocks* a requirement before asking uv for the newest resolvable version. For the `typing` group's `docutils~=0.20.0` that asks uv to resolve docutils 0.23 beside `sphinx~=7.4`, which forbids anything above 0.21. Under the default strategy that probe degrades to "no update for docutils" (which is why the 2026-09 batch, #1940, came through with three updates and no docutils); under `increase-if-necessary` it is fatal to the whole job. Both refreshes of #1940 after the merge failed that way, and the run triggered by the config change proposed nothing. Net effect: no dependabot updates of any kind. `lockfile-only` was the other candidate. It never unlocks, so it cannot hit this, and it never edits a manifest, but it also never proposes a release outside a range. 44 of the 97 external specifiers in these manifests carry a cap or a series, and the widening pull request is the one signal that a new major of one of them exists. Not worth the silence. ### What this does instead - `.github/dependabot.yml`: the option is removed, and the comment beside the uv block records both measurements and why the default stays. - `AGENTS.md`: one paragraph under *Pull request requirements* telling a reviewer of a dependabot uv pull request to read the `pyproject.toml` hunks, not only the lock; what the default strategy does to floors, caps and `~=` series, with #1940's three cases as the examples; and the procedure: keep the lock update, restore the specifier lines by hand on the dependabot branch, relock, and give a cap or series that really should move its own pull request (#1943 is the shape). ### After the merge Dependabot's run triggered by this config change should complete green on the Insights page, which is the proof the jobs are back. #1940 then gets its specifier lines restored by hand and is merged as the lock update it should have been; #1943 drops the click cap on its own reasoning. ### Checked `uv run poe lint` 8/8 (yamlfmt, taplo, check-readme included). No lock change.
chrisjsewell
added a commit
that referenced
this pull request
Sep 16, 2026
…pdates Per the review rule in AGENTS.md: dependabot's default strategy rewrote four specifier lines this batch did not need to touch. Restored by hand -- `matplotlib>=3.3.0` in sphinx-needs' `plotting` and `docs` extras and in the root `test` group (the floor already allowed 3.11.2), `uv>=0.12.9` in the root, and sphinx-codelinks' `click < 8.2` with its comment (a cap is lifted in its own pull request, #1943, not by a bot past the reason for it) -- then relocked. What remains is the lock update this batch is for: matplotlib 3.11.1 -> 3.11.2 and uv 0.12.9 -> 0.12.13. click stays at 8.1.8 until #1943.
chrisjsewell
force-pushed
the
deps/codelinks-click-cap
branch
from
September 16, 2026 09:18
965a7e0 to
ae7d26f
Compare
chrisjsewell
added a commit
that referenced
this pull request
Sep 16, 2026
…pdate Per the review rule in AGENTS.md. This batch rewrote six specifier lines it did not need to touch, three of them with NO corresponding lock change: `matplotlib>=3.3.0` in sphinx-needs' `plotting` and `docs` extras and in the root `test` group (the lock already had 3.11.2 from #1940), `uv>=0.12.9` (likewise 0.12.13 already), `prek>=0.5.2` (the floor already allowed 0.5.3), and sphinx-codelinks' `click < 8.2` with its comment (the cap is dropped in its own pull request, #1943). All restored by hand, then relocked. What remains is the one lock update this batch is for: prek 0.5.2 -> 0.5.3. click stays at 8.1.8 until #1943.
chrisjsewell
force-pushed
the
deps/codelinks-click-cap
branch
from
September 16, 2026 09:49
ae7d26f to
e155197
Compare
`"click < 8.2"` existed only to cap click below 8.2, working around click 8.2.0 printing an empty error when `codelinks` ran with no arguments -- an incompatibility in the typer of the time. Two things make it dead weight now: this package never imports click itself, and the typer it requires (0.27.2 in the lock) depends on annotated-doc, colorama, rich and shellingham, not on click. So the line was the ONLY reason click was in the environment at all, and `uv lock` removes click from the lock once it goes. Measured in the synced environment: `click` is not importable; `codelinks` with no arguments prints its usage panel and exits 2, and a bad subcommand prints the "No such command" error -- both exactly as before; `poe test-codelinks` 360 passed, 58 snapshots; `poe lint` 8/8. Dependabot's 2026-09 batch (#1940) proposed lifting the cap to `<8.6` past the comment explaining it, which is what prompted re-checking whether the cap still had a reason.
chrisjsewell
force-pushed
the
deps/codelinks-click-cap
branch
from
September 16, 2026 10:06
e155197 to
3c6e899
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removes one line from
packages/sphinx-codelinks/pyproject.toml,"click < 8.2", with a changelog bullet, and relocks. click leaves the lock entirely.Why the cap existed, and why it is dead
The line's comment said: click 8.2. produces empty errors if no args are given*. That was click 8.2.0 against the typer of the time, and the cap kept
codelinksprinting its usage panel when run bare.Two facts make it dead weight now, both measured on this branch:
git grepoversrc/: nothing);So the cap was the only reason click was installed at all, and
uv lockdrops click from the lock once the line goes.Checked
In the synced environment, with click no longer importable:
codelinkswith no arguments prints its usage panel and exits 2, exactly as before;codelinks nonsenseprints the "No such command" error panel, exactly as before;uv run poe test-codelinks: 360 passed, 58 snapshots;uv run poe lint: 8/8.Context
Dependabot's 2026-09 batch (#1940) proposed lifting the cap to
<8.6past the comment explaining it, which is what prompted re-checking whether the cap still had a reason. #1942 stops dependabot rewriting manifest specifiers like this in future; the deliberate lift is this pull request. Precedent for the shape: #1896, the typer cap.