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

Build Failure Summary

Root Cause Analysis: `model-index` Build Failure

Package: `model-index==0.1.11`
Build phase: `get_requires_for_build_wheel` (early build metadata resolution)

—

What Happened

The build failed with a `ModuleNotFoundError: No module named 'ordered_set'` during the setuptools build-backend hook `get_requires_for_build_wheel`.

The import chain that triggers the failure:

setup.py
  → modelindex/__init__.py (line 10)
    → modelindex/load_model_index.py (line 5)
      → modelindex/models/Model.py (line 5)
        → from ordered_set import OrderedSet   ← FAILS HERE

—

Why It Failed

This is a classic setup.py anti-pattern: the package's `setup.py` imports the `modelindex` package itself (typically to read `_version_` or other metadata). That import triggers a cascade of module-level imports, ultimately reaching `ordered_set` — a runtime dependency that is not installed in the build environment.

At this stage in the build, only the build-system dependencies (declared in `[build-system] requires` in `pyproject.toml`) are installed. For `model-index`, that's just `setuptools>=40.8.0`. The runtime dependency `ordered-set` is not available, so the import fails before setuptools can even determine what additional build dependencies are needed.

—

How to Fix It

Option 1 — Build dependency override (build-system level fix):
Add `ordered-set` to the build-system requirements for `model-index` in the build pipeline's configuration/overrides. This ensures `ordered-set` is present in the build environment when `setup.py` is executed.

Option 2 — Upstream patch (proper fix):
The `setup.py` should be refactored to avoid importing the package at build time. Common approaches include:

• Reading `_version_` from the file using `ast` or regex parsing instead of importing
• Moving version info to a static location (`pyproject.toml`, `setup.cfg`, or a plain-text `VERSION` file)
• Using a `try/except ImportError` guard around the problematic import chain

Option 1 is the pragmatic short-term fix for the build pipeline. Option 2 is the correct long-term solution but requires an upstream change to the `model-index` package.

Packaging Analysis Summary

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

Executive Summary: model-index Build Analysis

model-index (v0.1.11) is a pure-Python package with Simple build complexity (1/10) and no compiled extensions. It is MIT-licensed, and all four runtime dependencies (

pyyaml

,

markdown

,

ordered-set

,

click

) carry permissive licenses (MIT/BSD-3-Clause), making the full dependency chain fully compliant for Red Hat redistribution. The existing PyPI wheel (

py3-none-any

, 34 KB) is correctly formed with all dependencies properly declared in metadata and can serve as an immediate fallback. The repository (github.com/paperswithcode/model-index) has been unmaintained since June 2021.

The sole blocking issue is that

setup.py

imports the package at build time (

from modelindex import __version__

), triggering a cascade of imports that require all runtime dependencies to already be installed. This breaks PEP 517 isolated builds (pip's default behavior), making it impossible to build from sdist without intervention. Note: the JIRA ticket's description that runtime dependencies are "not properly declared in package metadata" is partially inaccurate — the wheel metadata is correct; the problem is specifically the build-time import chain in setup.py.

Recommended fix: Apply two patches — (1) create a

pyproject.toml

declaring runtime deps as build-system requires, and (2) patch

setup.py

to read the version string directly from

modelindex/version.py

via regex instead of importing the package. This eliminates the build isolation failure entirely. The patched build command is straightforward:

pip wheel --no-deps .
# Produces: model_index-0.1.11-py3-none-any.whl

As an alternative workaround, disabling build isolation (

pip install --no-build-isolation

) after pre-installing dependencies also works. No platform-specific builds are needed — a single

py3-none-any

wheel serves all architectures and Python 3 versions.

Key Takeaways

• Blocker:

  setup.py

  build-time import chain — fixable with a simple patch

• License: MIT + permissive deps — no redistribution concerns
• Risk: Repository unmaintained 4+ years; recommend carrying patches downstream
• Fallback: Existing PyPI wheel is correctly formed and installable as-is
• Target date (2026-03-04): Fully achievable — trivial package size, no compilation, single-session patch-and-build effort