Package 'google-auth-httplib2' does not build as-is via the AIPCC self-service pipeline and requires builder repository onboarding.

Build Failure Summary

Root Cause Analysis: `google-auth-httplib2` Build Failure

Summary

This is not a build failure of the `google-auth-httplib2` package itself. The pipeline fails during the requirements preparation phase, before any package building begins.

Root Cause

The requirements file at `/collection-repository/collections/torch-2.9.0/cpu-ubi9/requirements.txt` contains an invalid version specifier:

google-auth-httplib2==any

The `==any` version specifier is not valid per PEP 440. The `packaging` library's requirement parser rejects it because `any` is not a recognized version number:

packaging._tokenizer.ParserSyntaxError: Expected semicolon (after name with no version specifier) or end
    google-auth-httplib2==any
                        ^

The `prepare-requirements` tool calls `Requirement("google-auth-httplib2==any")`, which raises `InvalidRequirement`, and the pipeline aborts at line 0 of the requirements file.

Fix

Edit the requirements file (`requirements.txt` in the `torch-2.9.0/cpu-ubi9` collection) and replace the invalid entry. The correct syntax depends on the intent:

• To allow any version (most likely the intent of `==any`): remove the version specifier entirely:
  ```
  google-auth-httplib2
  ```

• To pin to a specific version: use a valid PEP 440 version, e.g.:
  ```
  google-auth-httplib2==0.2.0
  ```

Key Details

• Failing command: `prepare-requirements -o /mnt/computed-requirements.txt /mirror-builder/collections/global-requirements.txt /collection-repository/collections/torch-2.9.0/cpu-ubi9/requirements.txt`
• Failing file: `/collection-repository/collections/torch-2.9.0/cpu-ubi9/requirements.txt`, line 0
• No packages were built — the pipeline failed at the constraint/requirements preparation stage, so the bootstrap process never started.

Packaging Analysis Summary

Here is the executive summary formatted as a JIRA comment in JIRA wiki markup:

Executive Summary: google-auth-httplib2 Packaging Analysis

google-auth-httplib2 (v0.3.0) is a pure-Python, single-module package with a complexity score of 0/10 — making it one of the simplest packages to onboard. It provides an httplib2 transport adapter for Google Authentication and is a transitive dependency of google-api-python-client, which is the business justification for AIPCC-10796. The package requires no native compilation, has no system library dependencies, and produces a py3-none-any wheel that is architecture-independent. A single noarch build will cover all three target indexes (CPU, CUDA, ROCm). The source is licensed under Apache-2.0, fully compatible with Red Hat distribution policies, and the entire dependency chain uses permissive licenses.

The build system is straightforward setuptools with a declarative setup.py and no custom build logic. The only runtime dependencies are google-auth (>=1.32.0, <3.0.0) and httplib2 (>=0.19.0, <1.0.0). Building from source is trivial:

pip download google-auth-httplib2==0.3.0 --no-binary :all: --no-deps
pip wheel google_auth_httplib2-0.3.0.tar.gz --no-deps

Note: The transitive dependency chain includes cryptography (via google-auth), which does require native compilation (C/Rust) and should be handled separately in the build pipeline if building the full tree from source.

There are no critical blockers or known packaging issues. The original repository (googleapis/google-auth-library-python-httplib2) has been archived and its source deleted; the canonical source now lives in the googleapis/google-cloud-python monorepo under packages/google-auth-httplib2/. While the package carries a deprecation badge, Google continues active maintenance — the latest release (v0.3.0) shipped 2025-12-15 with Python 3.14 support, and the source was migrated to the active monorepo in February 2026. The deprecation is advisory only; the package remains a hard dependency of google-api-python-client.

Recommendation: Proceed immediately with onboarding version 0.3.0. No special environment configuration, build customizations, or workarounds are required. The 2026-03-15 target date has no risk factors. Default probe tests are sufficient for validation, with the package's own pytest suite available for additional coverage if desired.