Skip to content

Fix version() on repositories that tag with a leading "v" (r(170)) - #30

Open
jpazvd wants to merge 1 commit into
haghish:masterfrom
jpazvd:fix/tag-archive-folder-name
Open

Fix version() on repositories that tag with a leading "v" (r(170))#30
jpazvd wants to merge 1 commit into
haghish:masterfrom
jpazvd:fix/tag-archive-folder-name

Conversation

@jpazvd

@jpazvd jpazvd commented Aug 8, 2026

Copy link
Copy Markdown

github install <repo>, version(v1.2.3) fails with r(170) on any repository whose tags carry a leading v.

Cause

The archive downloads correctly, but GitHub names the folder inside it after the tag with the v removed. So the code unpacks <package>-v18.7.0.zip into <package>-18.7.0, then does cd <package>-v18.7.0 and stops.

Measured directly:

Repository Tag Archive root cd target
haghish/markdoc 5.0.2 markdoc-5.0.2 markdoc-5.0.2
jpazvd/yaml v2.0.1 yaml-2.0.1 yaml-v2.0.1
jpazvd/wbopendata v18.7.0 wbopendata-18.7.0 wbopendata-v18.7.0

Your own packages tag without the prefix, which is why this has not surfaced — but v-prefixed tags are common enough that version() is unusable for those repositories today.

A second case, same cause

The force path requests archive/master.zip and sets version master. GitHub still serves that archive for repositories that have renamed their default branch, but it unpacks into <package>-main. So cd <package>-master fails there too.

The change

Try the plausible names in order rather than assuming one. The expected name is tried first, so archives that already resolved are untouched.

I considered listing the directory instead and rejected it: the command unpacks into the user's working directory and leaves the folder behind, so a second install in the same directory leaves several <package>-* folders and makes discovery ambiguous. An earlier draft did exactly that and failed that way in testing.

Verified

Stata 17, in a directory deliberately holding four unpacked archives at once:

yaml       v2.0.1   -> yaml-2.0.1          (v stripped)
yaml       master   -> yaml-main           (default branch renamed)
markdoc    5.0.2    -> markdoc-5.0.2       (unchanged, first candidate)
wbopendata v18.7.0  -> wbopendata-18.7.0   (v stripped)
yaml       v9.9.9   -> clean error listing what was tried

The markdoc row is the no-regression check: it still resolves on the first candidate, exactly as before.

One note for anyone testing this — confirm file "dir/." is not a usable directory test here, returning 601 whether or not the directory exists. The patch uses capture cd, which the surrounding code already relies on.

Happy to adjust the style or the error wording if you'd prefer something different.

…rsion>

github install ... version(v1.2.3) fails with r(170) on any repository whose
tags carry a leading "v". The archive downloads fine, but GitHub names the
folder inside it after the tag with the "v" removed, so v18.7.0 unpacks into
<package>-18.7.0 while the code cds to <package>-v18.7.0 and stops.

The same mismatch affects the -force- path on repositories that have renamed
their default branch: archive/master.zip is served for them, but it unpacks
into <package>-main rather than <package>-master.

Rather than guess, try the plausible names in order. The expected name is
tried first, so archives that already resolved are unaffected -- verified
against haghish/markdoc 5.0.2, which still resolves on the first candidate.

Directory discovery was considered and rejected: this command unpacks into
the user's working directory and leaves the folder behind, so a second
install in the same directory leaves several <package>-* folders and makes
discovery ambiguous. An earlier draft used it and failed exactly that way
in testing.

Verified in Stata 17, in a directory holding four unpacked archives at once:

  yaml       v2.0.1   -> yaml-2.0.1          (v stripped)
  yaml       master   -> yaml-main           (default branch renamed)
  markdoc    5.0.2    -> markdoc-5.0.2       (unchanged, first candidate)
  wbopendata v18.7.0  -> wbopendata-18.7.0   (v stripped)
  yaml       v9.9.9   -> clean error listing what was tried

Note for anyone testing this: -confirm file "dir/."- is not a usable
directory test here; it returns 601 whether or not the directory exists.
capture cd is used instead, which the surrounding code already relies on.
Copilot AI lite review requested due to automatic review settings August 8, 2026 12:21

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes github install <repo>, version(<tag>) failures when GitHub’s ZIP archive unpacks into a directory name that doesn’t exactly match <package>-<version> (notably when tags are v-prefixed or when master.zip unpacks to -main).

Changes:

  • Tries multiple plausible unpacked directory names instead of assuming <package>-<version>.
  • Adds handling for v-prefixed tags (try the stripped-v directory name).
  • Adds handling for master/main default-branch mismatches by trying both suffixes.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread github.ado
if !`found' {
di as err "cannot locate the folder unpacked from `packagename'-`version'.zip"
di as txt "looked for: `candidates'"
exit 601
Comment thread github.ado
Comment on lines +556 to +557
local found 1
local dir "`c'"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants