fix(cli): avoid click<8.2 incompatibility in progressbar hidden kwarg - #407
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Replace direct typer.progressbar(hidden=...) calls with a _maybe_progressbar helper that skips the progress bar entirely when hidden. The hidden kwarg was added in click 8.2.0 but typer allows click>=8.0.0, causing TypeError for users with older click versions. Closes #404
Pygments was bumped to 2.20.0 (GHSA-5239-wwwm-4pmq fixed), so the uv-secure ignore entry is now unused.
Alberto-Codes
force-pushed
the
fix/cli-progressbar-click-compat
branch
from
May 8, 2026 21:10
02f8f05 to
4b8dd83
Compare
Alberto-Codes
marked this pull request as ready for review
May 8, 2026 21:12
There was a problem hiding this comment.
Pull request overview
Fixes a CLI runtime crash in environments using click<8.2 by avoiding the unsupported hidden kwarg path when constructing progress bars via Typer.
Changes:
- Introduces
_maybe_progressbarcontext manager to either show a real progress bar (show=True) or yield a plain iterator (show=False). - Replaces all runner usages of
typer.progressbar(..., hidden=...)with_maybe_progressbar(..., show=...)to preserve compatibility. - Updates and extends unit tests to mock
_maybe_progressbarand to directly test the helper’s behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/docvet/cli/_runners.py |
Adds _maybe_progressbar and routes runner progress display through it to avoid click<8.2 incompatibility. |
tests/unit/test_cli_progress.py |
Switches progress-bar mocking to _maybe_progressbar and adds focused unit tests for the helper. |
pyproject.toml |
Clears uv-secure vulnerability ignore list (removes prior suppression entry). |
Alberto-Codes
added a commit
that referenced
this pull request
May 8, 2026
🤖 I have created a release *beep* *boop* --- ## [1.15.1](v1.15.0...v1.15.1) (2026-05-08) ### Bug Fixes * **cli:** avoid click<8.2 incompatibility in progressbar hidden kwarg ([#407](#407)) ([00dbb82](00dbb82)), closes [#404](#404) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
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.
Users with
click < 8.2.0getTypeError: progressbar() got an unexpected keyword argument 'hidden'when running any docvet command.typer.progressbar()acceptshiddenin its own signature but passes it through toclick.progressbar(), which only addedhiddenin click 8.2.0. Since docvet declarestyper>=0.9(allowingclick>=8.0.0), environments can resolve to click 8.0.x/8.1.x where the kwarg doesn't exist._maybe_progressbarcontext manager that shows a real progress bar whenshow=Trueand yields a plain iterator whenshow=False, avoiding thehiddenkwarg entirelytyper.progressbar(..., hidden=not show_progress)calls in_runners.pywith_maybe_progressbar_maybe_progressbarinstead oftyper.progressbar, add direct unit tests for the helperTest:
uv run pytest tests/unit/test_cli_progress.py -vCloses #404
PR Review
Checklist
uv run pytest)uv run ruff check .)uv run ty check)!in title andBREAKING CHANGE:in bodyReview Focus
The
_maybe_progressbarhelper — confirms it correctly delegates totyper.progressbaronly whenshow=Trueand never passeshidden.Related