Module receipt 

What this project’s own installer did, written down beside the binary it installed.

Three programs used to derive the same facts independently — install.sh, install.ps1 and this binary each worked out which copy is the managed one, what the last install actually wrote, and whether the devp twin and the PATH entry came from us or were already there. Three derivations of one truth is how they drift, and the drift is invisible until an uninstall removes a PATH entry it never added.

So the installer writes it down. <bindir>/install.json sits next to the binary, is created by whichever installer performed the install, and survives the shell that ran it — which is the whole point, because a shell variable does not.

It is deliberately not a source of truth about the machine. Channel::detect stays the classifier: a receipt cannot describe a copy that arrived through cargo install, and a receipt that is missing means only that no installer of ours wrote one — never that the binary is unmanaged. Everything here is therefore advisory, read with Option, and reported rather than acted on.

Structs

Receipt

One install, as the installer that performed it saw it.

Constants

SCHEMA

The current on-disk shape.

Functions

load

Read the receipt, or None if there is not one worth trusting.

path

Where the receipt lives: beside the managed binary, in the one directory no package manager owns.

refresh_after_upgrade

Move an existing receipt forward after an in-place upgrade.

summary

One line for devp doctor and devp install: what the installer wrote, and when.

write

Write the receipt, replacing any previous one.