Idea: ship prebuilt binaries — Homebrew, Windows, Linux

[mellonis]

An idea capture, not a design: give people a way to get pmt/tmt without a Rust toolchain.

Motivation

Today the only way to obtain either binary is cargo install — i.e. install Rust first. That is fine for the audience that already has it, and it is a hard gate for the one that does not.

The gate matters more than it looks, because the editor plugins assume a binary on PATH. All four (VS Code and JetBrains, PM-1 and TM-1) shell out to pmt/tmt for LSP and DAP, and each declares a MIN_TESTED_PMT/MIN_TESTED_TMT floor — currently 0.4.0. So the plugin story is "install this extension, then install Rust, then cargo install two crates, then check your version is new enough". Someone who wants to look at a brainfuck universal Turing machine in their editor is not necessarily someone who wants a Rust toolchain.

Second, smaller point: v0.4.0's release attached four plugin artifacts and no binaries at all. Even a user who is happy to download something by hand has nothing to download.

Possible shapes, in dependency order

1. Prebuilt release binaries. The prerequisite for everything below, and the bulk of the work. A release workflow with a target matrix, artifacts attached to the GH release, built against the toolchain rust-toolchain.toml pins (1.98.0) so a packaged binary and a local build are the same compiler by construction. Candidate targets: aarch64-apple-darwin, x86_64-apple-darwin, x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu, x86_64-pc-windows-msvc. CI today (.github/workflows/test.yml) is ubuntu-only and runs on push to master / PRs against it, so this is a new workflow rather than an extension of that one.

2. A Homebrew tap (mellonis/homebrew-tap), one formula installing both binaries. Formula-from-source is the cheap version (brew installs Rust as a build dep, no bottles to maintain); pouring prebuilt bottles is faster for users and more upkeep. Worth deciding deliberately rather than by default.

3. Windows. A zip of the MSVC build gets most of the way. winget and scoop manifests are each a small increment on top of (1) — scoop especially, since it is just a JSON manifest pointing at a release asset.

4. Linux beyond tarballs. .deb/.rpm/AUR are real ongoing maintenance for a pre-1.0 project. My inclination is: tarballs from (1), and revisit only if someone asks.

Open questions

• One package or two? One repo, two CLIs, crates versioned in lockstep — a single machine-toolchains package installing both seems right, but it forecloses installing only the one you use.
• Shell completions. Homebrew conventionally installs completions into its own share dirs. pmt completions / tmt completions currently implement zsh only; bash and fish are recognised names that fail with a not-yet-implemented error. Packaging is the point where that gap becomes user-visible rather than theoretical — a formula that installs zsh completions and silently ships nothing for bash users is a worse experience than the current one. Either scope bash into this work or decide explicitly to ship zsh-only.
• Windows and completions generally — no completion story there at all today.
• Bottles vs from-source for brew (above), and whether the answer changes once (1) exists and the binaries are already built.
• Does this change the release checklist? The realized flow is: docs audit, bump crates + plugins + MIN_TESTED_* floors with the CHANGELOG entry, merge, tag, gh release create with plugin artifacts. Binary artifacts would slot into that last step, but the matrix build wants to run before the tag is published, not after.

Placement

Not before the C2 arc (#14) lands — it touches nothing this does, but it would compete for the same review attention. Most naturally part of a release round rather than a standalone change, since it modifies the release flow: 0.5.0 is the obvious candidate.

[mellonis]

Two of the open questions above now have their own tickets: shell completions for bash and fish are #119, man pages for both binaries are #120. Both are prerequisites of the Homebrew shape here rather than parts of it, so this issue stays about the binaries and the tap.

[mellonis]

One package or two — resolved: two. pmt and tmt package separately, one formula each in the tap.

The asymmetry that decides it: two packages do not foreclose "both" — a meta-formula depending on both is a few lines if anyone ever wants a single command — while one package forecloses "only one" forever. Two is the superset.

The repo already leans that way:

• The cargo path is per tool. There is no umbrella crate; each binary is auto-discovered from its own arch crate (crates/post-machine/src/bin/pmt.rs, crates/turing-machine/src/bin/tmt.rs), so cargo install already installs one or the other. A single Homebrew package would be the odd install path out.
• The editor plugins are per tool. The -pm and -tm pairs each shell out to their own binary with their own MIN_TESTED_* floor; a user with only the TM-1 extension has no reason to pull pmt.
• Completions (completions: bash and fish renderers over the registry — a prerequisite of packaging #119) and man pages (man pages for pmt and tmt — rendered from the CLI's own description, for packaging #120) are per binary regardless.

Cost: two formulas of near-identical boilerplate, two scoop/winget manifests, and two tarballs per target in the release matrix (ten assets for five targets). Lockstep versioning keeps that mechanical — same tag, same asset URL pattern, only the binary name differs. If bottles ever come, the bottle matrix doubles; that is the one recurring cost, and it stays hypothetical while the formulas build from source.

Naming: pmt/tmt are short and generic, but a personal tap namespaces them (mellonis/tap/pmt), so there is nothing to collide with unless they ever move to homebrew-core.