AlexsJones/llmfit · warning · ValueError

LLMFIT_PYTHON_PLATFORM_TAG is not supported for editable ins

Error message

LLMFIT_PYTHON_PLATFORM_TAG is not supported for editable installs. Let the build system detect the host platform instead.

What it means

initialize() rejects the combination of an editable build (version == 'editable', i.e. uv sync / pip install -e) with LLMFIT_PYTHON_PLATFORM_TAG set in the environment. Editable installs always use the locally compiled host binary from target/debug or target/release, so choosing a wheel platform for them is meaningless and would silently package the wrong artifact; the ValueError fails fast instead.

Source

Thrown at llmfit-python/hatch_build.py:169

        )
        output = result.stdout.strip()  # e.g. "llmfit 0.9.8"
        match = re.match(r"^llmfit v?(\d+\.\d+\.\d+)$", output)
        if not match:
            raise RuntimeError(f"Unexpected output from '{bin_path} --version': {output!r}")
        binary_version = match.group(1)
        if binary_version != expected_version:
            raise RuntimeError(
                f"Binary version mismatch: binary at {bin_path} reports {binary_version!r} "
                f"but Cargo.toml (or LLMFIT_VERSION) says {expected_version!r}. "
                "Run 'make build' to recompile.",
            )
        print(f"  Binary version OK ({binary_version})")

    def initialize(self, version: str, build_data: dict) -> None:
        """Locate the platform binary and configure the wheel before it is built."""
        py_target_from_env = os.environ.get("LLMFIT_PYTHON_PLATFORM_TAG")
        if version == "editable" and py_target_from_env:
            raise ValueError(
                "LLMFIT_PYTHON_PLATFORM_TAG is not supported for editable installs. "
                "Let the build system detect the host platform instead.",
            )
        running_platform = self._detect_platform()
        py_target = py_target_from_env or running_platform
        if py_target not in TARGET_CONFIGS:
            raise ValueError(
                f"Unknown LLMFIT_PYTHON_PLATFORM_TAG={py_target!r}. Must be one of: {sorted(TARGET_CONFIGS)}",
            )

        upstream_target, binary_name = TARGET_CONFIGS[py_target]
        pypi_version: str = self.metadata.version

        print(f"  target={upstream_target}  version={pypi_version}  wheel tag=py3-none-{py_target}")

        llmfit_root = Path(self.root).parent
        if version == "editable":
            # For editable installs, look for target/debug/llmfit or target/release/llmfit (or llmfit.exe on Windows).

View on GitHub (pinned to a9ac7ed91c)

Solutions

Unset the variable for the editable step: `unset LLMFIT_PYTHON_PLATFORM_TAG && uv sync`.
Split cross-build and editable/test steps into separate CI jobs or env blocks so the tag never leaks.
Check `env | grep LLMFIT` to find stray exports from shell rc files or direnv.
Only set the variable for standard wheel builds (`uv build`) where a cross-compiled target actually applies.

Example fix

# before
export LLMFIT_PYTHON_PLATFORM_TAG=manylinux_2_17_aarch64
uv sync  # ValueError: not supported for editable installs

# after
unset LLMFIT_PYTHON_PLATFORM_TAG
uv sync

Defensive patterns

Strategy: validation

Validate before calling

import os

if os.environ.get('UV_BUILD_MODE', 'editable') == 'editable':
    os.environ.pop('LLMFIT_PYTHON_PLATFORM_TAG', None)  # editable installs must not pin a platform

Prevention

Scope LLMFIT_PYTHON_PLATFORM_TAG to the single cross-build command line (`VAR=... uv build`), never `export` it job-wide.
Run editable installs (uv sync, pip install -e) in a clean env: `env -u LLMFIT_PYTHON_PLATFORM_TAG uv sync`.
Audit direnv/.bashrc/CI env blocks for leftover release variables.

When it happens

Trigger: Running `LLMFIT_PYTHON_PLATFORM_TAG=manylinux_2_17_aarch64 uv sync` or `... pip install -e .`; a CI job that exports the variable for a cross-build wheel stage and then reuses the same env for an editable-install test stage; the variable exported in ~/.bashrc or a direnv file leaking into local installs.

Common situations: Release pipelines that build multiple platform wheels in one runner and later run editable-based test suites without cleaning env; developers following the cross-compile docs and then trying a normal `uv run`.

Related errors

AI-assisted analysis of AlexsJones/llmfit@a9ac7ed91c (2026-08-16). Data as JSON: /api/errors/5e0e52aa7a981b71. Report an issue: GitHub.