The Python port dropped doctor's zephyrSdk check, reintroducing the exact defect #160 fixed: 'doctor: 0 failed' on a host with no cross-toolchain

[alpCaner]

Found by the maintainer on a clean Windows host running released v0.5.0-rc1, immediately after a successful tan bootstrap.

Measured

(.venv) PS> tan doctor --sdk-root C:\alp\ws\alp-sdk
[   pass] hostPython: Python 3.14 (`python`) meets the effective floor 3.12
[   warn] pythonFloor: ...
[   pass] hostPrerequisites: git, cmake, python, ninja present
[   pass] west: west 1.5 (C:\alp\ws\.venv\Scripts\west.EXE)
[unknown] setools: ...
[   warn] jlink: ...

3 passed, 2 warning(s), 0 failed.

0 failed on a host that cannot build for real silicon. The Zephyr SDK (arm-zephyr-eabi) is not installed — tan bootstrap had said so explicitly minutes earlier, in its own "NOT auto-installed" section. doctor does not mention it. It does not mention a toolchain at all.

This is a port regression against the Rust oracle

crates/tan-cli/src/commands/doctor.rs:371 calls append_zephyr_sdk_toolchain(&mut report), emitting a zephyrSdk check. Grepping the Python port:

$ grep -rn "zephyrSdk|zephyr_sdk|arm-zephyr-eabi" python/tan/commands/doctor_cmd.py
(no matches)

The check does not exist in python/tan/commands/doctor_cmd.py. Comparing the two check sets, Rust has hostPrerequisites, west and zephyrSdk; Python has the first two and not the third.

Why this specific check

The Rust docstring at doctor.rs:381-400 states the case, and it is precisely the run that just happened:

This is the check the alp-sdk#855 fresh-host run needed and never got: on that run tan doctor (plain) never mentioned the word "toolchain" at all, and tan doctor --build's equivalent check was reached only after tan init — a full project creation — stood between the user and the first sign of trouble. Surfacing it at the FIRST command a customer runs closes that gap directly.

tan-cli#160 added it to plain doctor for that reason. v0.5.0-rc1 reintroduces the defect #160 was written to close.

It is also load-bearing for documentation that shipped in this release: tan bootstrap's "Next steps" block tells the user, verbatim, that the Zephyr SDK is

"a separate manual install, which bootstrap does NOT install — the tan doctor above reports it, and names the exact install command"

That promise is now false.

Note on the check's intended shape

Per the same docstring, it is deliberately unconditional in plain doctor — a HOST fact (env var / scanned install dir, crate::toolchain::zephyr_sdk_detected), needing no board.yaml, no workspace and no SDK, because ADR 0021 Lane 1 P0a runs tan doctor before anything project-shaped exists. A Yocto-only project seeing it is the uncommon case and a Fail there is still true. Port it with that property intact rather than gating it on a Zephyr core.

Related, same session

The port also does not surface the incomplete venv bootstrap had just warned about (hidapi wheel build failed, #285) — doctor reports the venv's west as pass and says nothing about the missing package. Whether that belongs in this check or its own is a design call, but the user-visible effect compounds: two commands in a row told this host it was healthy when it was not.

Environment

tan 0.5.0-rc1 (Windows x64, attestation-verified), alp-sdk v0.15.0-rc1, workspace C:\alp\ws with Zephyr v4.4.1, venv active, west 1.5 present, no Zephyr SDK installed.

[hkngln]

Sibling filed as #290: the port also dropped doctor's westResolved, and dropping it reintroduces #123 the same way this one reintroduces #160. Same command, same shape — west_check (doctor_cmd.py:388) probes bare PATH where Rust (crates/tan-cli/src/commands/doctor.rs:298-310) reports the version of the west its own venv lookup resolved, guarded by a test named after #123.

Worth deciding together whether doctor needs one audit of every check the port dropped, rather than one issue per field as they are noticed.

[alpCaner]

Agreed on the audit — one pass over every check the port dropped, not one issue per field. Running now; #290 and this issue stay open as the two already-found instances, and whatever else it turns up gets filed against the same milestone.

The reason to do it your way rather than incrementally: both instances found so far are the same shape as the other RC defects this week — a check that measures a proxy instead of the thing it claims to measure. CI smoke-testing a cargo build while the release ships a PyInstaller freeze (#278), a freshness gate watching the wrong directory (#279), build reporting ok: true with every slice skipped (#283). Finding those one at a time has a poor hit rate because the shared property is invisible from any single instance.

#289 and #290 are now both on v0.5.0-rc2. #289 was carrying release-blocker with no milestone, and its argument holds — the un-activated-venv host is the extension's normal environment, so tool 'west' not found on every Zephyr slice is a regression against v0.4.1 on exactly the path customers use.

Status on this issue: the zephyrSdk port is in, plus the sevenZip sibling gated os.name == "nt" and not zephyr_sdk_ok to match crates/tan-core/src/build_readiness.rs:545, and a parity assertion for ZEPHYR_SDK_INSTALL_VERSION against contract/fixtures/toolchains/toolchains.json mirroring crates/tan-core/src/host_env.rs. Review then caught a blocker in it worth recording here, because it is the same failure mode again:

The first probe I specified was <root>/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc. That is the pre-0.17 layout. zephyr-sdk-1.0.1 puts the compiler under gnu/, per the maintainer's own build log on the host in question —

-- Found assembler: C:/Users/caner/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe

— so the "fix" would have converted a false Pass into a hard exit 4 refusal on every host with the pinned SDK. It passed 77 tests because the test helper planted the same wrong layout the probe looked for. Being fixed now, and it is a good argument for the audit probing against real measured tree shapes rather than fixtures authored alongside the code.

[alpCaner]

Audit done — filed as #294. Five dropped checks, one weakened, plus one documented divergence whose stated premise turns out to rest on one of the drops.

Reintroduced defects, with the guarding Rust test named in each case: #70 (zephyrSdkAvailableForHost/longPaths/homePath), #100 + #98/#159 (the whole sdk/boardYaml/workspace/zephyrVersion preflight, folded into plain tan doctor in Rust), #161 (posix_venv_unusable exists in the port at python/tan/core/bootstrap.py:1140 but is wired only into bootstrap, never doctor), and #203/#210 (data.missingPrerequisites absent from the envelope).

Findings 1-3 are the ones that let a host which cannot build report 0 failed — the same sentence #100 was filed with.

One severity correction worth having on the record: the first draft of that audit called the missingPrerequisites drop a crash. It is not. alp-sdk-vscode/src/deps/vscodeAdapter.ts:157 deliberately does not validate the key so that its absence survives as feature detection. What actually regresses is the affordance — vscodeAdapter.ts:379 runDependencyAction sends missingPrerequisites[].command to a terminal, so upgrading from a Rust tan to v0.5.0-rc1 silently loses the one-click dependency install. Graceful, but a real regression against v0.4.1 on the extension path.

All on v0.5.0-rc2. Happy to split #294 into per-defect issues if that suits triage better — the discovering is done either way.

[alpCaner]

Fixed in 0c131be, shipped in v0.5.0-rc2. zephyrSdk is back, plus the sevenZip sibling gated os.name == "nt" and not zephyr_sdk_ok to match crates/tan-core/src/build_readiness.rs:545 -- without 7-Zip the fix hint cannot be followed, since west sdk install shells to patoolib for .7z extraction with no pure-Python fallback.

Two defects were caught IN the fix, before release, and both are worth recording because they are the same shape as the issue itself:

• the probe first used the pre-0.17 SDK layout. In zephyr-sdk-1.0.1 the compiler is under gnu/, so the "fix" converted a false Pass into a hard exit 4 on EVERY host with the pinned SDK.
• HOME or USERPROFILE scanned one root, hard-failing a Git Bash host that HAD the SDK and had just built with it.

Both passed 77 tests, because the fixtures encoded the same wrong assumption as the code. The probe and the fixture now build from one ZEPHYR_SDK_TOOLCHAIN_DIR constant so they cannot drift back into agreeing only with each other.

The wider audit this prompted is #294.