fix(install): actionable error when GPU family has no wheels#111
fix(install): actionable error when GPU family has no wheels#111volen-silo wants to merge 2 commits into
Conversation
On a clean first run, `rocm install sdk` auto-detects the GPU family and resolves a TheRock index for it. When that family has no published wheel index the fetch 404s, and the command failed with an opaque error that left users to guess a working --family. Turn both the missing-index and unmapped-GPU failures into actionable guidance: name the resolved family, list the recognized --family values, and suggest the alternate channel/format. Wording differs for auto-detected versus user-supplied families. Deliberately no auto-fallback to a nearby family: installing wheels built for a different architecture can silently produce a broken runtime, which is worse than a clear stop on a first-run path. Signed-off-by: Eugene Volen <Eugene.Volen@amd.com>
|
🔴 Automated review · pr-review-watcher · 06950a1 SummaryTurns opaque HTTP-404 / "no artifact" install failures into actionable guidance by adding 🚫 Blocking (must fix before merge)None. Non-blocking
|
Signed-off-by: Michael Roy <michael.roy@amd.com>
michaelroy-amd
left a comment
michaelroy-amd
left a comment
There was a problem hiding this comment.
Reviewed the install-family guidance and focused tests. The known-family list round-trips through normalization, source-specific hints cover all three failure paths, and Windows correctly omits the unsupported tarball suggestion. The earlier Windows Strix Halo failures were cold backend-install timing rather than this diff; a focused rerun of both failed scenarios passed at the same head: https://github.com/ROCm/rocm-cli/actions/runs/29445489844.
2 participants
Problem
On a clean first run,
rocm install sdkauto-detects the GPU, normalizes it to a TheRockpackage family, and resolves a wheel/tarball index for that family. When the detected family
has no published index on the selected channel, the fetch returns HTTP 404 and the command
died with an opaque error:
Nothing told the user that
--familywas the escape hatch or which values are valid, so theonly recovery was to guess a working family.
Fix
Turn the opaque failures into actionable guidance:
known_therock_families()inrocm-core— the canonical set of families the CLIrecognizes (the full output set of
normalize_therock_family), guarded by a round-trip testso it can't drift from the normalizer.
family_resolution_hint()— a pure, tested message builder that names the resolvedfamily, lists the valid
--familyvalues, and suggests the alternate channel/format. Wordingdiffers for auto-detected vs. user-supplied families.
"no matching artifact" failure, and the "no supported family" bail.
Deliberately not done
No auto-fallback to a nearby family: installing wheels built for a different architecture can
silently produce a broken runtime, which is worse than a clear stop on a first-run path.
Testing
user-supplied, channel suggestions).
cargo test -p rocm-core -p rocm,cargo clippy --all-targets,cargo fmt --checkall clean.The end-to-end 404 path depends on live index endpoints and real hardware, so it is covered here
by the message-builder unit tests and left to the manual setup checklist for on-hardware
confirmation.