#247 was closed as completed, but four of its five distribution channels do not exist — and install friction is now a competitive position, not a convenience

[sotashimozono]

What #247 promised and what shipped

#247 ("Multiplatform Distribution Channels — npm/npx, Homebrew, deb/apt, curl, Nix") was closed as completed on 2026-06-20. Measured against the v0.8.9 release on 2026-08-25, what actually exists is:

channel	promised in #247	present today
curl installer	yes	yes — scripts/install.sh, scripts/install.ps1
npm / npx	yes	no — no npm package; nothing in the release assets
Homebrew tap	yes	no
Debian / apt	yes	no — no .deb asset
Nix flake	yes	partial/unknown — a flake.nix exists in the tree, but whether it exposes an installable package output rather than a dev shell was not checked

The v0.8.9 release assets are: four raw binaries (linux-x86_64, macos-aarch64, macos-x86_64, windows-x86_64.exe), one .mcpb, one CycloneDX SBOM, plus .sha256 and .cosign.bundle for each. Good artifacts, narrow channels.

README.md:114 still tells readers these channels are "tracked in #247" — a link to a closed issue. So the README currently points a reader at a completed ticket for work that was not done.

That is the same pattern #493 and #472 are about: a status claim that outran the thing it described. Reopening or superseding #247 is the smaller half of this issue; the larger half is below.

Why this stopped being a convenience item

The comparable MCP server in this niche (openags/paper-search-mcp, 2.5k stars, 249 forks, Python/MIT, actively maintained) ships seven install paths: Smithery, uvx, uv, pip, npx, Docker, and clone-from-source.

doiget's equivalent for a non-Rust user is: download a binary and put it on PATH, or install a C toolchain and cargo install doiget-cli. README.md:101-110 spends ten lines explaining that Windows users need Visual Studio Build Tools or MinGW-w64 before cargo install will link. That paragraph is an accurate description of a real barrier.

For an MCP server specifically, the channel that matters most is the one an agent config can name inline. npx -y <pkg> and uvx <pkg> are single lines in a config file with no prior install step; a downloaded binary is not. Every Claude Desktop / agent-runner config example in the ecosystem is written in that shape, and a tool that cannot be written that way is compared unfavourably before its behaviour is ever evaluated.

Suggested priority, highest first

1. npx — the MCP ecosystem's default invocation shape. A thin npm wrapper that downloads the matching signed release binary on first run, verifying the existing .sha256 / .cosign.bundle, keeps the Rust build out of the user's path while preserving the supply-chain story.
2. Docker — what enterprise and CI environments ask for, and the shape in which a security team can pin and scan an artifact. Also the natural answer to "run it inside our network with our own credentials", which is the only architecture the Tier-3 features can legally be used in.
3. Homebrew tap — macOS developer default; a tap is cheap to maintain from existing assets.
4. .deb — lower value; most Linux users will take the binary or the container.

cargo binstall deserves a mention: it needs no new channel, only correctly-named release assets, and may already work or nearly work. Worth checking before building anything.

Constraints worth stating up front

• Whatever is added must not weaken the release posture. Every current asset is cosign-keyless signed with a published SBOM; a wrapper that downloads a binary must verify it, not merely fetch it.
• ADR-0015 forbids self-update and phone-home. A first-run downloader is close enough to that boundary that it needs an explicit decision rather than an assumption — it downloads on install, not on use, and never checks for versions afterwards.
• More channels means more places a release can half-land. Proposal: Multiplatform Distribution Channels (npm/npx, Homebrew, deb/apt, curl, Nix) #247 was closed as completed while four fifths of it was not; whatever lands here should be asserted by the release pipeline, not by a checkbox.

Refs #247, #483, ADR-0015.

[sotashimozono]

Partially addressed by #531; keeping open for the rest.

Done there

• npx / npm — the priority-1 channel. Five package templates under npm/, staged by scripts/stage-npm.sh, published by a new npm-publish job over Trusted Publishing (OIDC, no long-lived NPM_TOKEN), after verifying each binary against the release's own .sha256. optionalDependencies rather than a postinstall download, for the four reasons this issue's constraints imply — --ignore-scripts is standard corporate policy, enterprises consume npm through a mirror, a fetched binary is outside npm's integrity hashes, and it is the shape a security review is trained to reject.
• README.md:114 no longer points readers at closed Proposal: Multiplatform Distribution Channels (npm/npx, Homebrew, deb/apt, curl, Nix) #247. It carries a status table naming what ships, what is not built, and what is unverified.

Still open, and the honest state of each

• Homebrew tap — not built. Cheap from existing assets; nobody has done it.
• .deb — not built. This issue rates it lowest and I agree.
• Docker — not built. This issue rates it [design] BiblioFetch.jl と TOML store の互換性レベル #2 and makes the strongest argument for it: it is the shape a security team can pin and scan, and the only architecture in which the Tier-3 features can legally be used. Worth more than the two above.
• Nix — flake.nix exists; whether it exposes an installable package output rather than a dev shell was not checked by this issue and was not checked by me either. The README says exactly that rather than guessing.
• cargo binstall — this issue notes it needs no new channel, only correctly-named release assets, and may already work. Also unchecked. It is the cheapest thing left on the list and should be tested before anything is built.

One constraint from this issue that the npm work honours

More channels means more places a release can half-land. #247 was closed as completed while four fifths of it was not; whatever lands here should be asserted by the release pipeline, not by a checkbox.

posture-lint now fails when the npm platform mapping drifts between the release matrix, scripts/stage-npm.sh and the bin shim — three hand-maintained copies of one table, which is the #454 / #504 shape. It does not yet assert that a channel published; the npm-publish job is continue-on-error: true so a failure does not fail a release, which means the log has to be read rather than assumed (#472).

Needs the maintainer

npm publishing needs a Trusted Publishing entry on npmjs.com for QAtlasHub/doiget → release-plz.yml, for each of the five package names. doiget and doiget-mcp were both free on 2026-08-26; the four platform names are unchecked.

[sotashimozono]

Re-measured against v0.8.12 (2026-08-29). Two rows change, and the priority list needs rewriting because one of its premises turned out to contradict an ADR.

Channel status now

channel	promised in #247	present today
curl installer	yes	yes
npm / npx	yes	yes — doiget-cli + four platform packages, live at 0.8.12
Homebrew tap	yes	no
Debian / apt	yes	no
Nix flake	yes	yes — see below

npm shipped. npm install -g doiget-cli puts doiget on PATH; npx -y doiget-cli serve runs the MCP server with nothing installed. Verified from the real registry, not from the staging tree. The wrapper is doiget-cli rather than doiget because npm permanently refuses the latter as too similar to the unrelated giget; matching the crate name was the better answer anyway.

Nix is no longer unknown. flake.nix exposes installable package outputs, not just a dev shell:

flake.nix:35   doiget = pkgs.rustPlatform.buildRustPackage { … };
flake.nix:68   packages.default = doiget;
flake.nix:69   packages.doiget  = doiget;

So nix profile install github:QAtlasHub/doiget should work. I have not executed it, so this is "the output exists" rather than "the install was exercised" — worth one run before the README claims it.

Docker: cutting it, and why

This issue ranks Docker second, on this reasoning:

Also the natural answer to "run it inside our network with our own credentials", which is the only architecture the Tier-3 features can legally be used in.

That premise does not hold. ADR-0002 decides that "the default published binary contains no TDM source code at all". A published image is built from the published binary, so it would ship oa-only,citation like every other prebuilt channel — no Tier 3. The architecture the sentence describes is real, but it is served by a user building from source with --features tdm-<publisher>, which is not a distribution channel.

The route itself exists: the MCP registry's schema accepts an oci package type alongside mcpb and cargo, so an image could sit in server.json next to the two already there.

registryType: ['npm', 'pypi', 'oci', 'nuget', 'mcpb']

What remains after removing the Tier-3 argument is "a shape enterprises can pin and scan". That is not nothing, but doiget is a single statically-linked binary — musl on Linux — so a container solves no dependency problem here. It adds a volume mount for the store and a release job, in exchange for a taggable digest that the existing .sha256 and cosign bundle already largely provide.

Revised priority

1. npx — done
2. Homebrew tap — macOS developer default, built from release assets that already exist, and the one remaining channel that removes real friction for a real audience
3. .deb — low value; most Linux users take the binary or Nix
4. Docker — cut, for the reasons above. Reopen if someone asks for it with a use case that survives ADR-0002