Document installing without the install script

[mattpodwysocki]

The only documented way to install was curl … | sh, which plenty of employers forbid outright. Nothing new has to be published for the alternative to work — manifest.json already lists every target with its checksum, the archives are plain HTTP, and each holds a single mapbox executable. This writes down what was already true.

Every command was run verbatim before being committed

Not adapted from the install script, not reasoned about:

mapbox-v0.2.1-aarch64-apple-darwin.tar.gz: OK
mapbox 0.2.1

Things that check turned up, which a plausible-looking doc would have got wrong:

• cli.mapbox.com/v0.2.1/… serves, and so does latest/…, but 0.2.1/… without the v is a 403. The version in the path is the tag, not the version string.
• shasum -a 256 -c SHA256SUMS fails for anyone who downloaded one archive, since the other four report as missing. grep "$file" SHA256SUMS | shasum -a 256 -c - is the form that works, and it's what the section says.
• The tarball has no wrapper directory — one file at the root — so there's no cd step and nothing else to place.

The builds are not signed, so that word is gone

The sentence above the install commands said Mapbox publishes signed builds. On the published macOS artifact:

Signature=adhoc
TeamIdentifier=not set
CodeDirectory … flags=0x20002(adhoc,linker-signed)

That's the linker's signature, which arm64 requires to execute at all — not a Mapbox one. I then grepped the publish pipeline for codesign, notarytool, signtool, certificates and keychains: there is no signing step anywhere, on any platform. What the install script actually checks is the SHA-256 checksum, which the same sentence already said correctly.

That has a consequence a manual installer meets and a curl … | sh user never does, so the section ends with it: curl attaches no quarantine flag (verified — the download carries only com.apple.provenance), a browser download does, and Gatekeeper refuses an unsigned binary carrying one. xattr -d com.apple.quarantine mapbox clears it.

I've filed the signing gap separately rather than leaving it as a README footnote — it's a pipeline change, not a docs one.

596 tests, cargo fmt --check clean, no broken in-page anchors, and the TOC has the new subsection.

[zmofei]

We already support specifying a version in the install command. Could we use that here instead of the manual steps?

For example:

curl -fsSL https://cli.mapbox.com/install.sh | MAPBOX_CLI_VERSION=v0.2.1 sh

[mattpodwysocki]

Half yes, half no — and the "no" half is why this section exists.

Why the manual steps stay

The section opens with "if piping one into a shell is not allowed where you work". curl … | MAPBOX_CLI_VERSION=v0.2.1 sh is still piping a script into a shell, so for the reader this section is written for, it isn't an alternative — it's the thing they already can't do. Plenty of shops block it outright, and a coding agent's sandbox refuses it, which is what prompted the section: mapbox/mapbox-cli-private#162 has the detail.

But you found a real gap, and I've fixed it

MAPBOX_CLI_VERSION appeared in no .md anywhere in this repository. Suggesting people use it meant suggesting something they had no way to discover — so your comment landed on a documentation bug, just not the one it was aimed at.

It's now documented in the install section, next to the install commands where someone pinning a version would look, along with MAPBOX_INSTALL_DIR which was also missing:

curl -fsSL https://cli.mapbox.com/install.sh | MAPBOX_CLI_VERSION=0.2.1 sh

And chasing it turned up that the variable was broken for the spelling anyone would actually use — a bare 0.2.1 403'd, because the channel's directories carry a v. Both are in #29, which also answers your note on #27.

So: this PR keeps the manual download steps, #29 documents and fixes the pinning. I think that covers what you were after from both directions — let me know if you'd still like something changed here.