-
Story
-
Resolution: Won't Do
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
-
Package 'gradio-client' does not build as-is via the AIPCC self-service pipeline and requires builder repository onboarding.
Build Failure Summary
Root Cause Analysis: `gradio-client` Build Failure
Summary
This is not a wheel build failure — the pipeline failed during the requirements preparation stage, before any package building began.
Root Cause
The requirements file at `/collection-repository/collections/torch-2.9.0/cpu-ubi9/requirements.txt` contains an invalid version specifier:
gradio-client==any
The string `any` is not a valid version per [PEP 440](https://peps.python.org/pep-0440/). The `packaging` library's requirement parser rejects it:
packaging.requirements.InvalidRequirement: Expected semicolon (after name with no version specifier) or end
gradio-client==any
^
The `prepare-requirements` tool calls `Requirement("gradio-client==any")`, which raises `InvalidRequirement`, causing the entire pipeline to abort at line 0 of the requirements file.
Fix
Replace the malformed entry in `requirements.txt`:
| Before (invalid) | After (valid) |
| — | — |
| `gradio-client==any` | `gradio-client` |
Removing the version specifier entirely means "any version is acceptable," which is the apparent intent of `==any`. Alternatively, if a specific version is known, pin it explicitly (e.g., `gradio-client==1.8.0`).
Key Details
- Failing tool: `prepare-requirements` (from `package_plugins.cli.prepare_requirements_constraints`)
- *Failing input file:* `/collection-repository/collections/torch-2.9.0/cpu-ubi9/requirements.txt`, line 0
- No packages were built — the failure occurred before the bootstrap/build phase started, so no `build-sequence-summary.md` or build logs were produced.
Packaging Analysis Summary
Here is the executive summary formatted as a JIRA comment in JIRA wiki markup:
Executive Summary: gradio-client Build Analysis
gradio-client (v2.1.0) is a pure Python library with Simple build complexity (1/10) and no compilation requirements. It uses the Hatchling build backend with full PEP 517/518 compliance, producing a universal py3-none-any wheel that serves all hardware indexes (CPU, CUDA, ROCm) without modification. The package is licensed under Apache-2.0, which is fully compliant with Red Hat redistribution policies. All five direct runtime dependencies (fsspec, httpx, huggingface-hub, packaging, typing-extensions) are permissively licensed. There are no critical blockers for onboarding, and the build completes in under 2 seconds producing a ~56KB wheel.
The source lives within the gradio-app/gradio monorepo on GitHub under client/python/, but the PyPI sdist is self-contained and does not require the full monorepo to build. The build process is straightforward:
pip install hatchling hatch-requirements-txt "hatch-fancy-pypi-readme>=22.5.0"
python -m build --wheel --no-isolation
No special environment variables, system libraries, or compilers are needed. For enterprise deployment, setting GRADIO_ANALYTICS_ENABLED=False and HF_HUB_DISABLE_TELEMETRY=1 is recommended to disable external telemetry.
The only notable consideration is a transitive dependency: huggingface-hub (>=0.19.3) pulls in hf-xet, a Rust-based native extension. This does not affect the gradio-client build itself, as pre-built manylinux wheels for hf-xet are available for x86_64. However, if building hf-xet from source is ever required, a Rust toolchain would be needed. Additionally, version coupling is strict – gradio 6.6.0 pins gradio-client==2.1.0 exactly, so the client version must match the targeted gradio version.
Key recommendations: Build from source using the PyPI sdist (recommended over monorepo checkout). No fallback strategy or container approach is needed due to the trivial build complexity. No open GitHub issues affect the build or installation of this package. No blockers exist for the 2026-03-15 target delivery date.
- is blocked by
-
AIPCC-10829 Add gradio-client into the RHAI pipeline onboarding collection
-
- Closed
-
- mentioned on