pty has no build identity at all, and three different numbers claim to be its version.
Today
pty --version → Unknown command: --version, exit 1. There is no version flag.- Three disagreeing version literals:
package.json → 0.10.0flake.nix → 0.1.0 (so the built store path is named pty-0.1.0)- a downstream conformance check asserts
pty 0.11.0
- Nothing in
src/ reads package.json, embeds a git rev, or carries a build stamp.
- The TUI and session-manager screens render no version; the wire protocol carries no version field; there is no telemetry, so no
service.version.
Net effect: given a running pty, there is no way to determine which source snapshot it was built from.
Proposed: adopt the shared build-identity contract
Model the same canonical fields we use in our other CLIs, and derive two outputs from them:
| field |
meaning |
baseVersion |
package version from the manifest |
rev |
short VCS revision of the built source |
dirty |
uncommitted changes present at build/run time |
sourceKind |
local (running from a checkout) or nix (packaged build) |
commitTs |
commit timestamp |
machineVersion — stable and parseable, for telemetry, APIs, logs, and exact comparison: 0.10.0, 0.10.0+7d5211e, 0.10.0+7d5211e-dirty. No prose, no relative time.displayVersion — human-facing, for --version and UI surfaces: 0.10.0+7d5211e — committed 4 days ago, with uncommitted changes.
Canonical names, so this stays consistent with our other tools:
- source placeholder:
__CLI_BUILD_STAMP__
- runtime env var for source runs:
CLI_BUILD_STAMP
Scope
- Add
pty --version, printing displayVersion; make machineVersion available internally for diagnostics.
- Inject the stamp at build time by substituting
__CLI_BUILD_STAMP__; fall back to CLI_BUILD_STAMP when running from source.
- Collapse the version literals to one source of truth — derive the flake
version from the manifest instead of maintaining a second number.
- Surface the same identity in the TUI (footer or debug view). Space-constrained surfaces may abbreviate but must not change semantics.
Unlike the sibling repos, pty is packaged by its own flake, so both halves — the CLI-side resolver and the build-time stamp injection — land here.
Sibling issues adopting the same contract: compoundingtech/smalltalk#103, compoundingtech/convoy#83. The three should land the same field names and the same two derived outputs so a version string means the same thing across the toolchain.
ptyhas no build identity at all, and three different numbers claim to be its version.Today
pty --version→Unknown command: --version, exit 1. There is no version flag.package.json→0.10.0flake.nix→0.1.0(so the built store path is namedpty-0.1.0)pty 0.11.0src/readspackage.json, embeds a git rev, or carries a build stamp.service.version.Net effect: given a running
pty, there is no way to determine which source snapshot it was built from.Proposed: adopt the shared build-identity contract
Model the same canonical fields we use in our other CLIs, and derive two outputs from them:
baseVersionrevdirtysourceKindlocal(running from a checkout) ornix(packaged build)commitTsmachineVersion— stable and parseable, for telemetry, APIs, logs, and exact comparison:0.10.0,0.10.0+7d5211e,0.10.0+7d5211e-dirty. No prose, no relative time.displayVersion— human-facing, for--versionand UI surfaces:0.10.0+7d5211e — committed 4 days ago, with uncommitted changes.Canonical names, so this stays consistent with our other tools:
__CLI_BUILD_STAMP__CLI_BUILD_STAMPScope
pty --version, printingdisplayVersion; makemachineVersionavailable internally for diagnostics.__CLI_BUILD_STAMP__; fall back toCLI_BUILD_STAMPwhen running from source.versionfrom the manifest instead of maintaining a second number.Unlike the sibling repos,
ptyis packaged by its own flake, so both halves — the CLI-side resolver and the build-time stamp injection — land here.Sibling issues adopting the same contract: compoundingtech/smalltalk#103, compoundingtech/convoy#83. The three should land the same field names and the same two derived outputs so a version string means the same thing across the toolchain.