Building a CLI with go-tool-base, part 1: scaffold and your first command
Install gtb, scaffold a releasable Go project, understand the generated and owned file split, then add your first command and run it.
Categories
78 pages
go-tool-base
The underpinnings for any Go command-line tool, and (as a few of my projects now prove) for comprehensive web services too. It standardises the boilerplate and wiring you end up writing in every Go project, and puts config, logging, self-update, a DI container and the rest straight at your fingertips. Highly opinionated, and it makes some calls people will disagree with, but it works, and it works really well. The CLI it ships with is a big part of that: keeping a Go app built, updated and maintained becomes almost trivial.
Pure-Rust Git, no git binary
Doing local Git from Rust with gix rather than shelling out to the git binary or linking libgit2, and why that avoids a lot of cross-compilation pain.
Why go-tool-base left GitHub for GitLab
An accidental major version bump was the last straw after months of unreliability. Why a Go framework moved off GitHub, and what moved with it.
Reloading config without a restart
Hot-reloading configuration: watch the file, re-read it, swap it in atomically and notify observers, without restarting a long-running service.
Verifying your own downloads: how I solved it for self-updating CLI tools
Self-update integrity for a CLI: verify the downloaded binary against the release checksums file, and decide whether to fail open or closed.
What survives a port, and what doesn't
Porting a Go framework to Rust separates design from idiom. Which decisions survived the move, which were habits, and how to tell them apart.
rust-tool-base: the same idea, in a language that argues back
A sibling to go-tool-base rather than a port, filling the gap between excellent Rust crates and a coherent way to assemble them.
The blank import that keeps a dependency out of your binary
Making OS-keychain support provably absent from a Go binary for regulated or air-gapped builds, using a registry and a blank import.
Where should a CLI keep your API keys?
Credential storage for a Go CLI: an env-var reference by default, an opt-in OS keychain, and plaintext only as a last resort and banned in CI.
A configurable AI endpoint is an attack surface
A user-settable AI base URL decides where your API key gets sent. Validating it to reject userinfo, non-HTTPS schemes and redirects.
