Skip to main content

Module install_info

Module install_info 

Source
Expand description

What this binary is and how it was installed – without a network call (#594).

An agent ran a doiget four releases old through the one surface that consumes oa_url programmatically, and nothing in the session said so: doiget_health reported a version with nothing to compare it against. A version check against the latest release is a network call nobody asked for, which ADR-0015 rules out; doiget version --check exists for a user who does ask. What can be reported for free is the rest of the picture:

  • the release channel the version belongs to (stable, or beta for a -beta.N build);
  • which binary is running – current_exe, the thing an MCP config names by path and a user never sees;
  • how it was installed, from the manifest scripts/install.sh / install.ps1 leave beside the binary, or else from where the binary lives (npm, cargo, Homebrew, Nix, a Claude Desktop .mcpb extension);
  • the command that updates it for that install method.

A manifest whose version differs from the running binary means the file was replaced by something other than the installer, which is said too.

Structs§

InstallInfo
The build and install report.
InstallManifest
What an installer recorded about the binary it placed.

Constants§

MANIFEST_NAME
File name of the manifest the installers write next to the binary.
UNKNOWN_VERSION
What an installer records when the new binary would not report its version: it names no version, so it is compared with none.

Functions§

describe
install_info from its inputs, for tests.
install_info
Report on the running binary. Reads at most one small local file.
parse_manifest
The manifest’s text as an InstallManifest, or None when it is not one: an unreadable manifest is reported as no manifest, and the method is read from the path instead. A leading BOM is allowed – Windows PowerShell 5.1 writes one with -Encoding UTF8, and older install.ps1 runs did.