Your Python Package Installed. Its CLI Crashed on --help.

The install succeeded. The CLI never stood a chance.

In May 2026, llama.cpp#23740 reported that uv tool install 'llama-cpp-scripts @ git+https://github.com/ggml-org/llama.cpp.git' worked fine — and then llama-convert-hf-to-gguf --help died instantly:

ModuleNotFoundError: No module named 'conversion'

The root cause is a packaging paper cut: since a refactor, the conversion scripts import from the new conversion/ package directory, but [tool.poetry] packages still said [{ include = "*.py", from = "." }]. A *.py glob does not match directories, so every built wheel shipped four entry points pointing at code that wasn't in the wheel. Running the scripts from the source tree worked — Python resolved conversion/ from the working directory — which is exactly why nobody noticed. Fixed upstream by PR #23746 on 2026-05-27, one config line — current llama.cpp no longer has this bug. What follows is a replay of the historical failure, which is exactly the point: the release passed CI, and nobody's check caught it for 12 days.

I reproduced this end to end: built the wheel at the pre-fix commit (zero conversion/ files inside), installed it in a clean venv, and got the identical ModuleNotFoundError at the identical line. Then applied the one-line fix, rebuilt (80 conversion/ files), and the import succeeded.

A second flavor of the same disease: SolaceLabs/solace-agent-mesh#1645. Editable installs generate a broken sam command — the entry points target solace_agent_mesh.cli.main:cli, but the CLI source lives in top-level cli/; wheel builds force-include it via Hatch while editable installs expose only src/. That repo is deprecated, so this one is still broken and won't be fixed.

The missing check

This is the sixth tool in my release-integrity series — the question each one asks is "the release passed, but what actually shipped?"

• readmeta: did your README render on PyPI, or are the images broken?
• wheeltruth: did your wheel ship complete, or are files missing?
• casecrash: will your filenames survive checkout on another OS?
• tagtruth: do your PyPI versions actually have matching Git tags?
• wheelreach: can your Python actually install what you declared it supports?
• entryprobe: does the installed CLI actually start?

entryprobe is a zero-dependency Python CLI with two modes. The default is a static check — no code runs:

pip install entryprobe
entryprobe check --wheel dist/mypackage-1.0-py3-none-any.whl

entry point              target                  verdict
-----------------------  ----------------------  --------------------
llama-convert-hf-to-gguf convert_hf_to_gguf:main UNKNOWN_IMPORT

checked 1 entry point(s), 1 problem(s)
  llama-convert-hf-to-gguf: entry point 'llama-convert-hf-to-gguf' (convert_hf_to_gguf)
  imports 'conversion': not in the distribution and not matching any declared
  dependency -- either a missing first-party module or a third-party import
  whose distribution name differs from its import name; review needed

It goes one level deeper than "is the target module there": it parses the target's module-level imports. Stdlib is skipped, Requires-Dist dependencies are expected (plus a small alias table for famous dist-name/import-name divergences like Pillow → PIL). Anything else absent is UNKNOWN_IMPORT — the tool can't tell a missing first-party module from a third-party import with a divergent name, so it says "review needed" instead of guessing. Lazy function-level imports and try/except ImportError fallbacks don't count — only what executes at import time decides whether an entry point starts.

The opt-in smoke test

Static analysis can't catch import errors inside a present module. So there's a second, explicitly opt-in mode:

entryprobe smoke --wheel dist/mypackage-1.0-py3-none-any.whl -- --help

This installs the wheel into a fresh temporary venv (--no-deps, deleted afterwards) and runs the entry point with exactly the arguments you typed. The safety contract is absolute: smoke only ever runs a local wheel file you name, with arguments you choose. It never downloads or executes arbitrary public packages.

Exit code 1 on problems, 0 when clean, 2 on errors — a post-release CI job. entryprobe check --package some-installed-pkg also works against installed distributions.

What entryprobe does not verify

The static check is one import level deep and syntactic: it proves the entry target and its import-time dependencies are present, not that importing them succeeds. A module can exist and still raise halfway through — that's what smoke is for, and smoke only runs what you hand it. C extensions and namespace packages get file-presence checks only. And a venv is not a security sandbox: smoke runs real code from a wheel you named, with access to your files and network — only smoke-test wheels you trust. And no checker can save you from a dependency that installs fine but behaves differently — that's a testing problem, not a packaging one.

The release passed. Now check what actually shipped: github.com/hahahahahahahahah6/entryprobe