Gradio Lite mostly dead on all Spaces?

[smartdigitalnetworks]

Anyone know why Gradio Lite fails on everyone Spaces. Lack of system resources? Could it be because it is an alternative to buying GPU time and running thing locally on uses machines in the browser?

The standard error seems to be…

Traceback (most recent call last): File “/lib/python3.12/site-packages/micropip/package_manager.py”, line 133, in install return await install( ^^^^^^^^^^^^^^ File “/lib/python3.12/site-packages/micropip/install.py”, line 57, in install raise ValueError( ValueError: Can’t find a pure Python 3 wheel for: ‘huggingface-hub<1.0,>=0.33.5’ See: Frequently Asked Questions — Version 0.29.0

T@https://cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.js:10:50928
new_error@https://cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.js:10:10028
<?>.wasm-function[308]@[wasm code]
<?>.wasm-function[507]@[wasm code]
<?>.wasm-function[4586]@[wasm code]
<?>.wasm-function[1151]@[wasm code]
<?>.wasm-function[3622]@[wasm code]
<?>.wasm-function[2184]@[wasm code]
<?>.wasm-function[1159]@[wasm code]
<?>.wasm-function[1162]@[wasm code]
<?>.wasm-function[1163]@[wasm code]
<?>.wasm-function[3428]@[wasm code]
<?>.wasm-function[3429]@[wasm code]
<?>.wasm-function[1165]@[wasm code]
<?>.wasm-function[1160]@[wasm code]
<?>.wasm-function[494]@[wasm code]
Xe@https://cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.js:10:62954
@https://cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.js:10:64132
wrapper@https://cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.js:10:27525

[John6666]

I think it’s better to wait for the infrastructure side to make the fix. @hysts

---

Gradio-Lite is breaking on Spaces because Pyodide’s package installer (micropip) can only install pure-Python or Pyodide-built wheels. Recent dependency resolution pulls a huggingface-hub requirement that micropip refuses to install, so the app never boots. The failing traceback and version range (huggingface-hub<1.0,>=0.33.5) are shown in your forum post.

What’s going on (short, then detailed)

• Short. Lite runs Python in the browser via Pyodide. Packages get fetched at runtime with micropip. If any transitive dep lacks a pure-Python wheel, install halts and Lite fails. That’s what you’re hitting. (Pyodide)
• Detailed. Pyodide accepts: (1) pure-Python wheels from PyPI and (2) wheels Pyodide prebuilt for WebAssembly. Anything else errors as “Can’t find a pure Python 3 wheel …”. This is by design. If a maintainer changes deps or publishes a version without a pure wheel, working Lite apps can break on rebuild. (Pyodide)

Fresh signals that match your failure

• New GitHub issue reproducing that Lite boot failure with the same error text and stack. (GitHub)
• Prior Lite breakages from dependency drift, e.g., pydantic mismatches under specific Pyodide versions. (GitHub)
• Other Lite-context failures that aren’t wheels but still bite browser mode (e.g., WebSocket timeouts). These confirm “works locally, fails in Lite” is common when browser constraints apply. (GitHub)

Root causes to watch for

1. Non-pure or missing wheels. micropip only installs pure-Python or Pyodide wheels. If resolution lands on any package without such a wheel, install fails. Error message is exactly what you saw. (Pyodide)
2. Dependency churn. A new lib or sub-dep can flip from “pure” to “needs native” or change constraints. Even small changes (e.g., pydantic switching lines) have broken Lite in the past. (GitHub)
3. Pyodide version mismatch. Older Lite embeds an older Pyodide. If your deps assume a newer baseline, import or wheel resolution breaks. (Pyodide)

Workarounds and fixes (ranked, least to most risk)

A. Avoid Python-side Hub calls inside Lite. Use JS clients.
Replace huggingface_hub in Python with JS APIs so micropip installs nothing. Use @huggingface/inference or @huggingface/hub from JS, or run models in-browser with Transformers.js. This sidesteps Python wheels entirely. (Hugging Face)

<!-- Use HF JS in the page; no Python deps -->
<script type="module">
  // @huggingface/inference docs: https://huggingface.co/docs/huggingface.js/en/inference/README
  import { HfInference } from "https://cdn.skypack.dev/@huggingface/inference";
  const hf = new HfInference("hf_xxx"); // supply token if model requires it
  // Example: text generation
  const out = await hf.textGeneration({ model: "meta-llama/Llama-3.1-8B-Instruct", inputs: "Hello" });
  console.log(out.generated_text);
</script>

B. If you want Python UI + in-browser models, use transformers-js via the official wrapper.
Install only the tiny Python wrapper transformers-js-py; the heavy lifting happens in JS. This pattern is the Gradio-recommended Lite path. (gradio.app)

<!-- Gradio-Lite + Transformers.js.py keeps deps Lite-safe -->
<script type="module" crossorigin src="https://cdn.jsdelivr.net/npm/@gradio/lite/dist/lite.js"></script>
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@gradio/lite/dist/lite.css"/>
<gradio-lite>
import gradio as gr
# transformers-js docs: https://huggingface.co/docs/transformers.js/en/index
# wrapper docs: https://www.gradio.app/4.44.1/guides/gradio-lite-and-transformers-js
from transformers_js_py import pipeline
pipe = await pipeline("sentiment-analysis")
demo = gr.Interface.from_pipeline(pipe)
demo.launch()
<gradio-requirements>
transformers-js-py
</gradio-requirements>
</gradio-lite>

C. Pin or remove problem packages in <gradio-requirements>.
Start from zero. Boot UI. Add one dep at a time. If adding huggingface_hub breaks, delete it and call the Hub from JS instead. If you must keep it, try an older known-good pin and test, but expect churn. (gradio.app)

D. Install from a direct wheel URL known to be pure.
micropip can install a specific wheel URL. If PyPI has a pure wheel for a working hub version, point to it explicitly. This can bypass resolver weirdness. (Micropip)

# In your <gradio-lite> Python block
# Micropip URL installs: https://micropip.pyodide.org/en/stable/project/usage.html
import micropip
await micropip.install("https://files.pythonhosted.org/packages/.../huggingface_hub-0.XX.X-py3-none-any.whl")

E. Use keep_going=True once to discover every offender.
Get a complete list of missing wheels instead of failing on the first one. Then eliminate or replace them. (Micropip)

# List all packages without compatible wheels
import micropip
try:
    await micropip.install(["your", "deps", "here"], keep_going=True)
except Exception as e:
    print(e)  # shows all missing/pinned offenders

F. Bump to latest Lite and thus newer Pyodide.
Load the newest @gradio/lite so you inherit a newer Pyodide and wider built-in wheel set. Regression risk exists but often fixes old incompatibilities. (Pyodide)

G. If you truly need Python packages with native code, don’t use Lite.
Move that app to a normal CPU/GPU Space where pip can install platform wheels. Browser Python cannot build or load native extensions. (Pyodide)

Triage checklist you can run today

1. Rebuild with an empty <gradio-requirements> and confirm the UI loads. Then add deps one by one. When it breaks, you found the blocker. (gradio.app)
2. If the blocker is huggingface_hub, remove it and switch to JS clients or Transformers.js for the same task. (Hugging Face)
3. If you insist on Python Hub, try an explicit pure wheel URL for a version you’ve verified on PyPI has py3-none-any.whl. (Pyodide)
4. Run once with keep_going=True to list all missing wheels. Eliminate or replace them. (Micropip)
5. Upgrade @gradio/lite to latest to pick up a newer Pyodide. Re-test. (Pyodide)
6. If networking APIs fail in Lite (timeouts/WS), call them from JS or move off Lite. Browser constraints differ from server Python. (GitHub)

Background: why JS routes are the stable path

• JS SDKs (@huggingface/inference, @huggingface/hub) talk to Hugging Face services directly. No Python, no wheels, no micropip. Stable in browser. (Hugging Face)
• Transformers.js runs models on WebGPU/CPU in the browser. The Gradio team documents the transformers-js-py bridge specifically to make Lite apps dependency-light. (gradio.app)

References and similar reports

• New GitHub issue: same huggingface-hub wheel error halts Lite. (GitHub)
• Prior Lite issues: pydantic versioning under Pyodide; browser-only API timeouts. (GitHub)
• Pyodide docs: pure-Python wheel requirement, package loading rules. (Pyodide)
• Gradio-Lite guides: <gradio-requirements> usage and Transformers.js patterns. (gradio.app)

Short, curated extras

How Lite works and how to debug

• Gradio-Lite intro and debugging tip (check browser console). Useful when your app shows a blank screen. (Hugging Face)

Pyodide specifics

• micropip usage and direct-URL installs. Handy for explicit wheel pins. (Micropip)
• Pyodide package list. Check what’s already prebuilt before adding deps. (Pyodide)

---

Here’s what to do if you were the HF infra team and want to fix the root cause (and stop this class of breakages from recurring).

---

TL;DR (actionable)

1. Upgrade the Pyodide version used by @gradio/lite on Spaces to ≥ 0.27.6 (prefer latest stable) — 0.27.6 fixes a micropip bug with package names containing dashes, which directly affects huggingface-hub (dash in dist name, underscore in module). The failing threads show Lite running on Pyodide 0.27.3. (Hugging Face Forums)

2. Ship a curated, locked Lite environment:

   • Generate and publish a pyodide-lock.json (via micropip.freeze) for the official Lite template + demo, and load it with Pyodide’s lockFileURL so dependency resolution is frozen and reproducible. (micropip.pyodide.org)
   • Add an internal constraints list and alternate index to micropip (supported params) so Spaces can prefer a vetted index/mirror for Lite-only packages. (micropip.pyodide.org)

3. Make Lite defaults avoid Python Hub where possible:

   • Update templates/docs to prefer HuggingFace.js or Transformers.js for browser inference and Hub calls; keep Python UI minimal. This sidesteps wheels entirely. (gradio.app)

4. Gate-keep bad deps early:

   • Add a preflight “Lite compatibility” check during Space build: run micropip.install(..., keep_going=True) against the <gradio-requirements> to list all non-installable wheels and fail fast with guidance. (micropip.pyodide.org)

[hysts]

@John6666

I think it’s better to wait for the infrastructure side to make the fix.

Not sure if I understand what you mean. Is this really an infra issue?

FYI, gradio-lite is no longer maintained. GitHub - gradio-app/gradio-lite: The gradio repo frozen at the final release of gradio-lite

[John6666]

FYI, gradio-lite is no longer maintained.

Thank you! Oh… I didn’t know that.
In that case, it’s not an infrastructure problem…
Probably just the library being out of date…

[John6666]

Hmm, I wonder if this will at least get around the error for now?

<gradio-requirements>
# choose a version that satisfies <1.0,>=0.33.5
huggingface_hub==0.36.0
</gradio-requirements>

[smartdigitalnetworks]

Thank you so much for replying to this issue. Gradio-lite as a solutions is really amazing.

I had not noticed”gradio-lite is no longer maintained”.

As an outsider looking in that is truly sad. When I found the solution I figured Nvidia as a GPU maker or AWS as a cloud service would find it and kill it to stop it’s use in an effort to sell more cloud services and more GPU.

I had used it for projects on my personal server in the past.

I was so happy to find it as an option when setting up a static space when making a new Hugging Face Space.

Screenshot 2025-11-01 at 1.58.57 PM

I configured 5 simple test Spaces to make sure it worked before moving on to more complex uses. Here is an example of the most simple, not even using requirements.

Screenshot 2025-11-01 at 2.07.25 PM

Screenshot 2025-11-01 at 2.07.08 PM

What I found was it often would load just fine on its first run and would fail to build nearly every time after that. If I reload the page dozens of times it most often will NOT build and run. About 99% of the time it errors, but the same unchanged code will load and run from time to time. That is why I thought it might have been a resource or infrastructure issue.

Screenshot 2025-11-01 at 2.04.10 PM

Screenshot 2025-11-01 at 2.04.25 PM

Screenshot 2025-11-01 at 2.05.11 PM

If it does not work at its simplist form, I would hope it would not be included as an option when setting up a space.

And since Hugging face has many paying members using it, if it is an issue at “pyodide” maybe you all would have a better chance of addressing them to fix the issue if it is on their end.

In the case of this simple app. If you look at the time stamps I included it built fine at 2:04 today. At 2:05 when I clicked reload page it failed to run with no code changes. I reloaded the page a few times only to have it fail.

I started this replay to this post and went back and hit reload page at 2:20 and it built just fine.

Screenshot 2025-11-01 at 2.20.24 PM

So I just don’t understand why it builds and runs a few times, but not every time if I am not changing the code.

The other reason I really enjoyed using it was I do not understand the issue with the “pure-python-wheel-for-a-package” and this solution allowed me to build simple things without knowing more about that process. I will now spend a considerable amount of time trying to learn more about it. Having been a software engineer for 35 years I am continually finding something I missed learning, so thank you for the tips on where to look.

Here are the links to the five Spaces I built.

I would hope the default gradio-lite space would build and run as I said above, it is an option on the new spaces menu and it seems to fail.

Screenshot 2025-11-01 at 2.28.53 PM

Screenshot 2025-11-01 at 2.29.04 PM

Screenshot 2025-11-01 at 2.29.19 PM

And it seems that something simple like this would work every time and it seems to fail with great irregularity. This space does not even use any requirements and it fails.

Screenshot 2025-11-01 at 2-1.20.24 PM

Screenshot 2025-11-01 at 2.31.08 PM

Screenshot 2025-11-01 at 2-1.33.31 PM

I VERY, VERY much appreciate all your help. I’m not one to ask for help very often and thought this might fall on deaf ears. So again THANK YOU so very, very much.

I will read and reread the above to try and figure it out. I just hate the idea of looking for an issue that is something I have no ability to solve.

I did try adding “huggingface_hub==0.36.0” to the requirement in this space which is a duplicate of the new Hugging face - Static Space - Gradio-lite option. but it didn’t seem to help the error.

It did not load before the edit.

Screenshot 2025-11-01 at 2.40.32 PM

Screenshot 2025-11-01 at 2.40.55 PM

It loaded once after that edit.

Screenshot 2025-11-01 at 2.41.31 PM

Screenshot 2025-11-01 at 2.42.01 PM

Screenshot 2025-11-01 at 2.42.15 PM

Screenshot 2025-11-01 at 2.45.45 PM

And failed to reload nearly every time after that initial load.

Again I can’t thank you enough for your help. I tried to make sure to include the time of the tests above in each image hoping that helps.

Also when I search hugging face spaces nearly every space using gradio-lite seems to be failing in this way not. Which is truly sad for the growth of the industry as not all of us have investors to help us cover the cost of cloud solutions or GPUs.

Screenshot 2025-11-01 at 2.58.44 PM

As a newer user of the forum it would not allow me to include all the screen shots so I’ve attempted to attach them as a zip. https://smartdigitalnetworks.com/huggingfacegradiolitespaceerrors.zip Hope this helps.

∞:heart:∞

[John6666]

If you pin the version to an older one, it might work…?

If you’re not set on Gradio-Lite, there are several JavaScript frameworks maintained on the browser like Transformers.js.