Summary
cds get's GitHub tarball download (_download_github_repository in
cli/getter.py, introduced in #493) requires the extracted archive to
contain exactly one top-level directory entry:
extracted_entries = [entry for entry in extract_root.iterdir() if entry.is_dir()]
if len(extracted_entries) != 1:
raise GetError(f"Unexpected archive layout for {owner}/{repo}@{ref}")
GitHub's tarball API is documented to always produce a single top-level
owner-repo-sha/ directory, so this should hold in practice. But if that
assumption is ever violated (format change, empty archive, a proxy/mirror
altering the response, etc.), the resulting error message gives no
actionable diagnostic -- it doesn't say how many entries were found, or
list their names, making it hard for a user or maintainer to debug.
Proposed fix
Include the actual entries found (names, and whether they're files vs.
directories) in the GetError message, e.g.:
raise GetError(
f"Unexpected archive layout for {owner}/{repo}@{ref}: "
f"expected exactly one top-level directory, found "
f"{[e.name for e in extract_root.iterdir()]}"
)
Context
Raised as a minor, non-blocking observation during review of #493.
Summary
cds get's GitHub tarball download (_download_github_repositoryincli/getter.py, introduced in #493) requires the extracted archive tocontain exactly one top-level directory entry:
GitHub's tarball API is documented to always produce a single top-level
owner-repo-sha/directory, so this should hold in practice. But if thatassumption is ever violated (format change, empty archive, a proxy/mirror
altering the response, etc.), the resulting error message gives no
actionable diagnostic -- it doesn't say how many entries were found, or
list their names, making it hard for a user or maintainer to debug.
Proposed fix
Include the actual entries found (names, and whether they're files vs.
directories) in the
GetErrormessage, e.g.:Context
Raised as a minor, non-blocking observation during review of #493.