The published asset filename leaks into --help usage text and the cli.parse-error envelope

[alpCaner]

Found while building and exercising the v0.5.0-rc1 Windows freeze before tagging. Cosmetic and pre-existing — filing so it is not rediscovered as a freeze regression.

What happens

The program name in usage/help/parse-error text derives from sys.argv[0]'s basename rather than a fixed "tan". Verified both ways from the same clean venv:

• frozen: tan.exe
• python -m tan: python -m tan

release.yml renames the artefact to its target-triple asset name on upload, so what a user who downloads and runs it directly actually sees is:

Usage: tan-x86_64-pc-windows-msvc.exe [OPTIONS] COMMAND [ARGS]...

and the same string lands inside the JSON envelope, in data.message for cli.parse-error. That second one is the part worth caring about: the envelope is a consumer contract, and a machine-readable field whose content varies by how the binary was named is a poor thing to have there.

Users are told to put the binary on PATH as tan, so most will never see it — but the ones who run the downloaded file in place, and any consumer keying off that message, will.

Also, unrelated and equally cosmetic

tan init --som <SKU> rewrites the scaffolded board.yaml's sku: value but leaves the trailing comment stale — e.g. sku: E1M-V2N101 # Alif Ensemble E8 SoM. Substituting the SKU should either update or drop that comment.

Not a blocker

Neither affects behaviour. Recording both because the freeze verification that surfaced them was a one-off (tan-cli#278: CI's first blink/first install still smoke-test the Rust binary, so nothing routinely exercises the real asset).

[alpCaner]

Root cause found, and it explains why no test catches this. Raised by the maintainer asking the obvious question — don't we use Typer? We do (typer>=0.12, with click>=8.1), and Click takes an explicit prog_name. The problem is which call sites pass it.

python/tan/cli.py:256 — the JSON help-envelope path, exercised by tests:

result = CliRunner().invoke(get_command(app), argv, prog_name="tan")

python/tan/cli.py:507 and :530 — the two REAL entrypoints:

app()          # :507, non-JSON path
...
app()          # :530, --format json path

Bare app(), so Click falls back to deriving the program name from sys.argv[0]'s basename.

The only invocation that pins prog_name="tan" is the one the test harness uses. So the tests are structurally incapable of observing the defect: they hardcode the correct value that production omits. That is why this reached a release and only surfaced when a human ran the downloaded asset under its published filename.

That reframes the severity. It is still cosmetic in effect, but the shape — a test harness supplying a value production does not — is the same blind-spot class as tan-cli#278 (CI smoke-testing a cargo build of crates/ while the release ships a PyInstaller freeze). Worth fixing the same way: make production and test agree, rather than making the test assert the current output.

Fix: pass prog_name="tan" at both :507 and :530. Then a test that drives the real entrypoint — not CliRunner with the name pre-supplied — can actually pin it, including in the cli.parse-error envelope's data.message, which is the part that matters for consumers.

[alpCaner]

Fixed in 204c3a0, shipped in v0.5.0-rc2. The published asset filename no longer leaks into --help usage text or the cli.parse-error envelope -- production passes the same prog_name the tests did.