dbt-labs/dbt-core · error · RuntimeError

no prebuilt {name} {ver} wheel for this platform; available

Error message

no prebuilt {name} {ver} wheel for this platform; available platforms: {plats}

What it means

The PEP 517 build backend's `_select_wheel` iterates pip's compatible platform tags (`sys_tags()`) looking for a match in the sdist's embedded `assets.json` manifest. If none of the machine's platform tags appears in the manifest's `wheels` map, it concludes no prebuilt wheel was published for this platform and raises RuntimeError listing which platforms ARE available.

Source

Thrown at crates/dbt-ci/templates/sdist_build_backend.py:38

_HERE = Path(__file__).resolve().parent
_MANIFEST = json.loads((_HERE / "assets.json").read_text(encoding="utf-8"))

_RETRIES = 4
_TIMEOUT = 60


def _select_wheel():
    """Pick the manifest wheel for the first platform tag this machine accepts.

    ``sys_tags()`` is pip's ordered list of compatible tags, so the most specific
    build wins.
    """
    wheels = _MANIFEST["wheels"]
    for tag in sys_tags():
        entry = wheels.get(tag.platform)
        if entry is not None:
            return entry
    raise RuntimeError(
        "no prebuilt {name} {ver} wheel for this platform; "
        "available platforms: {plats}".format(
            name=_MANIFEST["name"],
            ver=_MANIFEST["version"],
            plats=", ".join(sorted(wheels)),
        )
    )


def _emit_notice():
    """Print the manifest's install-time notice, if it carries one.

    pip and uv run the build backend as a subprocess and only surface its output
    when the build *fails*, so stderr alone would hide this from a normal
    install. Writing to the controlling terminal as well is best-effort: with no
    tty (CI, redirected output, Windows with no console) it just falls through to
    stderr, where `-v` and the pip log still pick it up. Both land under `-v`,
    which is better than the notice going unseen.

View on GitHub (pinned to 0267ce9170)

Solutions

Check the error's 'available platforms' list against your platform; if supported, upgrade pip to ensure correct platform tagging
Pin to a release version that includes wheels for your platform
Build/install from source or use a platform whose tag matches a listed wheel
Regenerate/publish wheels for the missing platform with `dbt-ci pypi pack`

Example fix

// before (unsupported platform)
pip install mypkg  # musl container
// after
FROM gcr.io/...:manylinux  # or pin a release with musl wheels
pip install mypkg==1.2.3

Defensive patterns

Strategy: validation

Validate before calling

import json, pathlib
manifest = json.loads(pathlib.Path('assets.json').read_text())
from packaging.tags import sys_tags
compatible = [t.platform for t in sys_tags() if t.platform in manifest['wheels']]
if not compatible:
    print('unsupported platform; available:', sorted(manifest['wheels']))

Type guard

def has_prebuilt_wheel(manifest: dict) -> bool:
    from packaging.tags import sys_tags
    wheels = manifest.get("wheels", {})
    return any(t.platform in wheels for t in sys_tags())

Try / catch

try:
    entry = _select_wheel()
except RuntimeError as e:
    print(f"no wheel for this platform: {e}")
    sys.exit(1)  # or fall back to source build

Prevention

Check the release's supported platforms list before installing on exotic OS/arch combos
Keep pip current so platform tags are accurate
Prefer manylinux/macOS/Windows mainstream platforms or pin a release with wheels for yours
If you control the release, publish wheels for every platform you claim to support

When it happens

Trigger: `pip install` of the sdist runs `build_wheel`, which calls `_select_wheel`; the current OS/arch (or Python ABI implied by the tags) has no entry in the manifest's `wheels` mapping.

Common situations: Installing on an unsupported platform (e.g. Alpine/musl, FreeBSD, linux armv7) or a very new OS/arch released after the wheels were published; a partial release where the pack tool only published wheels for some platforms; mixing up platform tag naming between manifest generation and install-time.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/a9101c6d311a6892. Report an issue: GitHub.