Package manager distribution (Homebrew, Linux packages, WinGet/Scoop, crates.io)

[shengyfu]

Umbrella issue for making tgrep installable through native package managers.

Follows on from #107, which asks specifically for a Homebrew formula. The same gap applies to Linux and Windows users.

Current state

The only documented install paths are:

• cargo install --path tgrep-cli --locked after cloning the repo
• manually downloading a tarball/zip from Releases and extracting it onto PATH

There is no package manager story on any platform, and nothing published to crates.io.

The good news is that .github/workflows/release.yml already produces the artifacts packaging needs:

• x86_64-unknown-linux-musl
• aarch64-unknown-linux-musl
• x86_64-apple-darwin
• aarch64-apple-darwin
• Windows zip

So most of this is packaging and release automation rather than new build work.

Proposed scope

macOS + Linux — Homebrew (covers #107)

Publish a formula to a microsoft/homebrew-tap so users can run brew install microsoft/tap/tgrep. Homebrew works on Linux as well, so a single bottle-less formula pointing at the existing release tarballs covers both platforms. Moving to homebrew-core later is possible once the project meets its notability requirements.

Linux — native packages

• .deb via cargo-deb and .rpm via cargo-generate-rpm, attached to each GitHub release
• optionally a Nix derivation and an AUR PKGBUILD (both are typically community-maintained)

Windows — WinGet and/or Scoop

Submit a WinGet manifest and/or a Scoop bucket entry built from the existing Windows zip.

Cross-platform — crates.io

Publishing tgrep-cli to crates.io makes cargo install tgrep work without cloning the repo. This is the cheapest win and benefits every platform at once.

Release automation

Whatever we adopt needs a bump step in the release workflow so formulas/manifests are updated with the new version and checksums automatically. Otherwise these go stale within a release or two.

Suggested order

1. crates.io publish (lowest effort, immediate cross-platform benefit)
2. Homebrew tap (closes Homebrew formulae? #107, highest demand)
3. .deb/.rpm artifacts on releases
4. WinGet/Scoop
5. Automate version + checksum bumps in release.yml

Docs

Update the Installation section of README.md as each channel lands.

[shengyfu]

Did a complexity assessment on this. Bottom line: low-to-moderate — no build work needed, since release.yml already produces every artifact packaging requires (musl x64/arm64, darwin x64/arm64, signed Windows zips) plus a checksums.txt formulas can consume directly. It is publishing plumbing and credentials, not code.

Channel	Effort	Main friction
crates.io	~1-2 hrs	tgrep name taken; path dep missing version
Homebrew tap	~0.5 day	New tap repo + cross-repo write token
.deb/.rpm release assets	~0.5 day	None major (hosted apt/yum repo is a separate, larger project)
WinGet/Scoop	~1-2 days	ADO/GitHub split; Windows publish is manual
Bump automation	~1 day	Touches all of the above

Roughly 3-5 focused days for everything, or under a day to close #107 specifically via a Homebrew tap + crates.io publish.

Four concrete findings worth knowing before we start:

1. The tgrep crate name is taken on crates.io by niamster/tgrep ("Toy grep that honors .gitignore"), v1.6.15, still updated as of March 2026. So cargo install tgrep is unavailable; it would be cargo install tgrep-cli (binary is still tgrep).

2. Publishing is blocked by a one-line manifest issue. Confirmed by dry run:

   error: all dependencies must have a version requirement specified when publishing.
   dependency `tgrep-core` does not specify a version
   

   Fix is tgrep-core = { path = "tgrep-core", version = "1.0.2" } in the root Cargo.toml, then publish core before cli. Otherwise metadata is already publish-ready and cargo package --list succeeds.

3. homebrew-core is not viable yet — its notability bar is ~75 stars / 30 forks / 30 watchers and we are at 64 / 9 / 1. A microsoft/homebrew-tap is the right call now. Good news: the tgrep formula name is free in homebrew-core for later. No shell completions or man pages exist in the CLI today, so the formula stays minimal.

4. WinGet/Scoop is the awkward one, not because manifests are hard but because Windows binaries come from a different CI system: sign-and-release.yml runs in ADO OneBranch with trigger: none and only uploads to GitHub when PublishToGitHub is manually flipped to true (defaults to false). Any automated manifest bump cannot just hang off the GitHub release event. The upside is those binaries are already Authenticode-signed, which WinGet prefers.

Suggested order: crates.io, then the Homebrew tap, then bump automation for both before adding more channels, then .deb/.rpm, then WinGet/Scoop.