docs: document every install route, not just building from source - #6
Merged
Conversation
The Installation section offered only `go install` and a source build, even though v1.2.0/v1.3.0 publish .tar.gz/.deb/.rpm for amd64 and arm64 and an AUR package has existed since v1.1.0. The path most users want was undocumented. Rewritten as four routes -- AUR, .deb/.rpm, prebuilt tarball, from source -- leading with the packaged ones, which need no Go toolchain. The rule this enforces: every install route must be able to follow every other instruction in the README. The live-theme-switching section offered /usr/share/tailtui/... (packages) or contrib/... (clone), which strands anyone who ran `go install` -- they have neither. Added a curl line fetching the template from raw.githubusercontent.com. Also documents the two `go install` caveats: the binary lands in $GOBIN/$GOPATH/bin, which is not necessarily on PATH, and a source build installs the binary alone. The tarball snippet resolves the current tag from the API rather than embedding a version, so it does not break on the next release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Why
The Installation section offered only
go installand a source build — despite v1.2.0/v1.3.0 publishing.tar.gz,.deband.rpmfor amd64 and arm64, and an AUR package existing since v1.1.0. The install path most users actually want was undocumented, and both documented paths require a Go toolchain for what is otherwise a dependency-free binary.The rule worth keeping
Every install route must be able to follow every other instruction in the README.
The live-theme-switching section offered two ways to get the template —
/usr/share/tailtui/…(packages) orcontrib/…(a clone). Anyone who rango installhas neither, so that instruction was unfollowable for them. Same class of defect as the packaging gap fixed in #5, just stranding a different group.Fixed with a third
curlline fetching the template fromraw.githubusercontent.com.Changes
.deb/.rpm, prebuilt tarball, from source — packaged ones firstgo installcaveats:$GOBIN/$GOPATH/binisn't always onPATH, and a source build installs only the binaryRequirementsclarified — Go is needed only for a source buildAvoiding rot
The tarball snippet resolves the current tag from the API rather than embedding a version:
A
releases/latest/download/tailtui_1.3.0_…URL works only while 1.3.0 is latest — it 404s the moment v1.4.0 ships, because the filename embeds the version. Verified the snippet resolvesv1.3.0and downloads successfully.Scope
Docs only. No Go, test or packaging changes, and no version bump — nothing user-facing changed in the program itself.