fix: bump gradio to v5 (resolves HfFolder ImportError on Space)#3
Merged
Conversation
The deployed leaderboard Space crashed at runtime with: ImportError: cannot import name 'HfFolder' from 'huggingface_hub' Cause: gradio 4.x imports `HfFolder` from `huggingface_hub`, but `huggingface-hub` 1.0 removed that name. The Space container resolves both unbounded and ends up with `gradio==4.44.0` + `huggingface-hub>=1`, which is the broken combination. Gradio 5 dropped the `HfFolder` import. Changes: - `pyproject.toml`: bump `gradio>=4.44` -> `gradio>=5` in both the `leaderboard` and `dev` extras (with a one-line comment recording why). - `hf-space/README.md`: bump Space metadata `sdk_version` 4.44.0 -> 5.9.1. - `uv.lock`: re-resolved. - `Makefile`: add `make leaderboard-hf` that mirrors what the deployed Space does (loads summaries from `commoncrawl/commonlid-results` instead of `./data/results/`), so we can smoke-test the Space entrypoint locally before pushing. Verified locally: `make leaderboard-hf` boots the Gradio app under gradio 6.14.0 (the latest 6.x in our resolve), serves on 127.0.0.1:7860, populates the leaderboard tabs from the live HF dataset. No Space-side warnings about sdk_version mismatch (HF Spaces docs: "All versions of Gradio are supported"). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add tests/hf-space/test_space_entrypoint.py with two tests:
1. `test_space_app_py_boots_and_returns_blocks` — loads
`hf-space/app.py` exactly the way the Space runtime does (top-level
module via `spec_from_file_location`, not via the package), with
`commonlid.leaderboard.app.build_app` patched to read summaries from
a tmp_path so we never touch the network. Asserts the resulting
`demo` is a `gradio.Blocks` instance.
2. `test_gradio_imports_cleanly` — direct guard against the failure
mode that took the production Space down: gradio 4.x + huggingface-
hub 1.0 raised `ImportError: cannot import name 'HfFolder'` from
inside gradio's own import chain. The existing leaderboard tests
used `pytest.importorskip("gradio")`, which silently skips on any
`ImportError` and would have hidden a broken-gradio environment
behind a green CI badge. The new helper checks installation via
`importlib.metadata` so the suite skips only when gradio is *truly
missing* and fails when it's installed but broken.
Verified: both tests pass under the current `gradio>=5` resolve, and
both fail hard with the original `HfFolder` ImportError when forced
into a fresh venv with `gradio==4.44.0 huggingface-hub==1.14.0`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.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
1 participant
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.
Summary
The leaderboard Space (commoncrawl/commonlid) failed to boot with:
gradio4.x importsHfFolderfromhuggingface_hub.huggingface-hub1.0 removed that name. Both deps were unbounded above, so the Space container resolvedgradio==4.44.0+huggingface-hub>=1.0— the broken combination. Gradio 5 dropped theHfFolderimport.Changes
pyproject.toml: bumpgradio>=4.44→gradio>=5in both theleaderboardanddevextras, with a one-line comment recording the reason.hf-space/README.md: bump Space metadatasdk_version4.44.0→5.9.1.uv.lock: re-resolved (only the twogradioconstraint markers change; the locked version moves up).Makefile: addmake leaderboard-hfthat mirrors what the deployed Space does — loads summaries fromcommoncrawl/commonlid-results(the live HF dataset) instead of./data/results/. Lets us smoke-test the Space entrypoint locally before pushing without needing a populated local results tree.Test plan
make lint,make format-check,make typecheck,make test— all green (231 passed, 94.60% coverage)make leaderboard-hf— boots the Gradio app locally under gradio6.14.0(the latest 6.x our>=5constraint resolves to), serves on127.0.0.1:7860, populates the leaderboard tabs from the live HF dataset. UI renders correctly (per-dataset tabs + per-row drilldowns work).hf-space/to the Space and confirm the build no longer crashes onHfFolder.Compatibility note
Our app uses only the most stable subset of the Gradio API (
Blocks,Tabs,Tab,Markdown,Dataframe,Accordion,SelectData). All forward-compatible across Gradio 4 → 5 → 6, so the only user-visible change is the bug fix.🤖 Generated with Claude Code