AlexsJones/llmfit · error · FileNotFoundError

Binary not found at {bin_path}. The binary selection logic s

Error message

Binary not found at {bin_path}. The binary selection logic selected a file that does not exist.

What it means

A defensive re-check in initialize(): both selection helpers (_find_local_binary and _find_binary_for_target) already verify the file exists and raise their own errors, so this FileNotFoundError can only fire if the chosen path stopped being a file between selection and this check - a race such as a concurrent cargo clean, the artifact living on a flaky mount, antivirus quarantining the fresh binary on Windows, or a broken symlink at one of the candidate paths.

Source

Thrown at llmfit-python/hatch_build.py:197

        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).
            bin_path = self._find_local_binary(llmfit_root)
        elif version == "standard":
            # For release installs, look for e.g. target/x86_64-unknown-linux-gnu/release/llmfit on Linux.
            bin_path = self._find_binary_for_target(llmfit_root, py_target)
        else:
            raise ValueError(f"Unknown version: {version!r}")

        # Always check that the binary exists.
        if not bin_path.is_file():
            raise FileNotFoundError(
                f"Binary not found at {bin_path}. The binary selection logic selected a file that does not exist.",
            )

        # If possible, check the self-reported version of the binary.
        # If the binary was built for a different platform then it's not possible.
        if py_target == running_platform:
            self._check_binary_version(bin_path, pypi_version)

        # Place the binary in the wheel's scripts directory so that the
        # installer puts it in .venv/bin/ (or Scripts/ on Windows).
        build_data["shared_scripts"][str(bin_path.absolute())] = binary_name

        # Override the platform tag so the wheel gets the correct platform-specific name.
        build_data["tag"] = f"py3-none-{py_target}"
        build_data["pure_python"] = False

View on GitHub (pinned to a9ac7ed91c)

Solutions

  1. Re-run the build after the concurrent operation finishes; serialize cargo clean and uv build steps.
  2. Verify the printed path manually (`ls -l <bin_path>`) - if it is a dangling symlink, delete it and rebuild.
  3. Give each CI job its own workspace/target directory instead of sharing one.
  4. On Windows, add an exclusion for the repo's target/ directory in antivirus, or mark the pipeline to tolerate rescans.
Defensive patterns

Strategy: validation

Validate before calling

from pathlib import Path

bin_path = Path('target') / 'x86_64-unknown-linux-gnu' / 'release' / 'llmfit'
if not (bin_path.is_file() and not bin_path.is_symlink()):
    raise SystemExit(f'{bin_path} missing or a symlink; rebuild with cargo build --release --target x86_64-unknown-linux-gnu')

Prevention

When it happens

Trigger: Two build jobs sharing one target/ directory where one runs `cargo clean` while the other is mid-`uv build`; a symlinked target/debug/llmfit pointing at a deleted file (is_file() follows symlinks); Windows Defender removing the just-built unsigned exe between cargo finishing and the hook's stat call.

Common situations: Parallel CI jobs on a shared workspace or network volume; developer running `make clean` in another terminal during a build; security software interfering on Windows runners.

Related errors


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