Re-enable progress bars when CLI output mode is explicitly human - #4879
Re-enable progress bars when CLI output mode is explicitly human#4879xbsheng wants to merge 1 commit into
Conversation
`Output.set_mode()` disables progress bars for any non-human mode but never re-enables them. In an agent-detected session (e.g. a Warp terminal, see huggingface#4860), the CLI starts in `auto` -> agent, bars get disabled, and a later explicit `--format human` keeps them off. This is independent of the auto-detection fix: only enables progress bars when the user explicitly asks for human output.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d9e7583. Configure here.
| if mode != OutputFormat.human: | ||
| disable_progress_bars() | ||
| else: | ||
| enable_progress_bars() |
There was a problem hiding this comment.
Human mode warns when bars disabled
Low Severity
set_mode now calls enable_progress_bars for every human-mode resolution, including Output construction and auto detection. That helper emits a UserWarning when HF_HUB_DISABLE_PROGRESS_BARS is set, so a normal hf command writes a warning to stderr even though bars were already intentionally disabled.
Reviewed by Cursor Bugbot for commit d9e7583. Configure here.
|
closing in favor of #4878 |


Fixes part of #4860.
Problem
Output.set_mode()disables progress bars for any non-human mode but never re-enables them:In an agent-detected session (the current
autodetection flags every Warp terminal, see #4860), the CLI starts withauto->agentand progress bars are disabled. A later explicithf ... --format humankeeps them off:set_mode(human)only changesself.mode, it never callsenable_progress_bars().Change
src/huggingface_hub/cli/_output.py:set_mode(human)now callsenable_progress_bars().tests/test_cli_output.py: new test assertingset_mode(AGENT)disables andset_mode(HUMAN)re-enables the global progress-bar state.This is independent of the auto-detection fix and works without any TTY sniffing.
Note
Low Risk
Small CLI output-mode change with no auth, data, or API impact; only affects global tqdm/progress-bar visibility.
Overview
Fixes progress bars staying off after switching the CLI to human output.
Output.set_mode()already calleddisable_progress_bars()for non-human modes (agent, json, quiet) but did not turn them back on when mode becamehuman—so a session that started in agent/auto could keep bars disabled even withhf ... --format human.set_mode()now callsenable_progress_bars()when the resolved mode is human, mirroring the existing disable path. A new test checks agent → human toggles the global progress-bar flag and restores state in teardown.Reviewed by Cursor Bugbot for commit d9e7583. Bugbot is set up for automated code reviews on this repo. Configure here.