Repository navigation
[FIX] the installer stopped just before it configured anything - #74
Merged
Merged
Conversation
`install.sh` runs under `set -e`, and `install_magi` was a bare call. Every path
out of it that could not install the sidecar returns 1 — the download failed,
there is no Swift to build from source, the build failed — and those are
warnings by design: `orrery magi` hard-fails later and the rest of orrery works.
As a bare call, that warning ended the script.
What it took with it was everything below: the PATH check, the version banner,
`orrery-bin setup`, and the instructions to source activate.sh. The install left
binaries in `/usr/local/bin` and nothing else — no `~/.orrery`, no rc entry, and
no `orrery` command, because that is a shell function `setup` writes. The last
line printed was a warning that reads as harmless, so it looked like an optional
extra had been skipped.
Found by installing on a clean Linux machine, not by reading the script. It does
not reproduce by inspection: the magi download normally succeeds, the call
returns 0, and nothing looks wrong.
The second commit here is the reason it took a wrong turn first. `curl` exits
the same way for a 404 and for a connection that dropped, and the message
reported both as "not available for ${os}-${arch}". The linux-x86_64 asset
exists — magi v1.1.4 publishes all three platforms — so the real event was a
dropped fetch on a slow link, and the message sent me looking for a missing port
that was never missing. It now says the fetch failed and names both causes.
Verified by A/B on a clean machine with the magi fetch forced to fail and no
Swift present. Before: exit 1, no activate.sh, zero rc entries, binaries
installed. After: exit 0, activate.sh written, three rc entries, and the script
ends on the activation banner.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
docs/install.shruns underset -e, andinstall_magiwas a bare call. Every path out of it that could not install the sidecar returns 1 — download failed, no Swift to build from source, build failed — and those are warnings by design:orrery magihard-fails later, the rest of orrery works fine.As a bare call, that warning ended the script.
Everything below it never ran: the PATH check, the version banner,
orrery-bin setup, and the instructions to sourceactivate.sh. The user was left with binaries in/usr/local/binand nothing else — no~/.orrery, no rc entry, and noorrerycommand, since that is a shell functionsetupwrites. The last line printed was a warning that reads as harmless, so it looked like an optional extra had been skipped.The fix is
install_magi || true. The file already used that idiom two lines later (VERSION=$(… || true)), so this was the same oversight missing one spot.The second commit, and why the first diagnosis was wrong
curlexits the same way for a 404 and for a connection that dropped. The installer reported both asnot available for ${os}-${arch}.That message is wrong:
orrery-magi-linux-x86_64.tar.gzdoes exist — magi v1.1.4 publishes darwin-arm64, linux-arm64 and linux-x86_64. The real event was a fetch that died mid-stream on a slow link (this VM measures ~110 KB/s to GitHub). The message sent me looking for a missing asset that was never missing, and I initially wrote this up as "Linux has no prebuilt magi, so every clean install hits it" — which would have been a false claim in the changelog.It now says the fetch failed and names both possible causes. The trigger for the bug is therefore any failed magi install, most often a flaky network — not a platform gap.
Verification
A/B on a clean Linux x86_64 machine, magi fetch forced to fail, Swift genuinely absent:
~/.orrery/activate.sh/usr/local/binBoth halves were run so the test discriminates — one that passed in both directions would prove nothing.
The
beforecolumn is what a user actually received.🤖 Generated with Claude Code