go install github.com/excelano/blick-cli@latest will install a command named blick-cli. Everything else — the README, the landing page, the demos, the deb, the Homebrew formula, the eget line — calls it blick. Someone who installs the Go way gets a binary whose name matches nothing in the docs.
This is not a bug in Go. A main package at the module root takes its binary name from the last element of the module path, and the module path has to end in blick-cli because that is the repo name. Bare go build already shows it: it now writes blick-cli where it used to write blick.
How this surfaced
The module path was module blick, which is not a resolvable remote path, so go install failed outright rather than producing a misnamed binary. Changing it to module github.com/excelano/blick-cli fixes the resolution — one line, no import rewrites, since every file here is package main at the root; build, vet, and tests pass. That change turns a hard failure into a working-but-misnamed install, which is what this issue is about.
What is left
1. Move the main package into cmd/blick/. This is the actual fix. The install path becomes go install github.com/excelano/blick-cli/cmd/blick@latest, the binary is named blick, and the layout matches xql and xfiles, which already put their mains under cmd/<tool>/. It is a move of roughly twenty-five files plus a main: path update in .goreleaser.yml; there are no import paths to rewrite because there are no internal packages. Worth also dropping /blick-cli from .gitignore afterward, since bare go build goes back to emitting blick.
2. Cut a release. The module proxy serves the tagged go.mod, so @latest keeps resolving to the old module blick until a new tag exists. No go install line should be published before that.
3. Version stamping (fleet-wide, tracked separately). go install does not run GoReleaser, so the ldflag-injected version is empty and --version reports the placeholder instead of the release number. The fix is a debug.ReadBuildInfo() fallback when the ldflag variable is unset — Go stamps the resolved module version into BuildInfo.Main.Version for pkg@latest installs. Additive; the ldflag path still wins when GoReleaser sets it. This applies to all six Go tools, not just this one.
Until 1 and 2 land, the go install line for blick should be held rather than published with a footnote about the binary name.
go install github.com/excelano/blick-cli@latestwill install a command namedblick-cli. Everything else — the README, the landing page, the demos, the deb, the Homebrew formula, the eget line — calls itblick. Someone who installs the Go way gets a binary whose name matches nothing in the docs.This is not a bug in Go. A main package at the module root takes its binary name from the last element of the module path, and the module path has to end in
blick-clibecause that is the repo name. Barego buildalready shows it: it now writesblick-cliwhere it used to writeblick.How this surfaced
The module path was
module blick, which is not a resolvable remote path, sogo installfailed outright rather than producing a misnamed binary. Changing it tomodule github.com/excelano/blick-clifixes the resolution — one line, no import rewrites, since every file here ispackage mainat the root; build, vet, and tests pass. That change turns a hard failure into a working-but-misnamed install, which is what this issue is about.What is left
1. Move the main package into
cmd/blick/. This is the actual fix. The install path becomesgo install github.com/excelano/blick-cli/cmd/blick@latest, the binary is namedblick, and the layout matches xql and xfiles, which already put their mains undercmd/<tool>/. It is a move of roughly twenty-five files plus amain:path update in.goreleaser.yml; there are no import paths to rewrite because there are no internal packages. Worth also dropping/blick-clifrom.gitignoreafterward, since barego buildgoes back to emittingblick.2. Cut a release. The module proxy serves the tagged
go.mod, so@latestkeeps resolving to the oldmodule blickuntil a new tag exists. No go install line should be published before that.3. Version stamping (fleet-wide, tracked separately).
go installdoes not run GoReleaser, so the ldflag-injected version is empty and--versionreports the placeholder instead of the release number. The fix is adebug.ReadBuildInfo()fallback when the ldflag variable is unset — Go stamps the resolved module version intoBuildInfo.Main.Versionforpkg@latestinstalls. Additive; the ldflag path still wins when GoReleaser sets it. This applies to all six Go tools, not just this one.Until 1 and 2 land, the
go installline for blick should be held rather than published with a footnote about the binary name.